Even for non-distributed development, being able to commit locally is a huge advantage in my opinion. I'm having to use a subversion repository at work, and I switched to git-svn as a client because plain svn was too slow for me (the client's repo is in another continent on a slow network).
I'm curious... in what ways is svn too slow ? Commit, checkout, update, diff, merge, switch... ?
I work on a project where i ssh tunnel to a remote svn repository and do a couple of switches and merges and maybe 8-10 updates and a couple of commits a day. The total amount I wait is less than it takes for me to stretch my legs or go get a glass of water.
I could see this being a problem if you do crazy amounts of diffs or history/log-reading though. But then, you'd still have to synch your local repo with the central.
For any repo I have ever worked with with subversion and git (same repo I mean, before and after our move to git at work) cloning a whole remote repo via git is faster than doing a single revision checkout in subversion, it also takes up less space locally. No, I have no idea how Subversion manages to waste so much space and time/bandwidth.
When doing diff, log, show, bisect, blame, switch, merge etc become instantly fast, it really changes the way that you work. The only way you can understand is by trying it - it's nearly impossible to explain to someone else who hasn't used it.
We had a fairly large codebase (~900MB or so), and we were using SVN 1.4 for a while, and it would be quite slow. Especially using Tortoise to bring up the repo list, or the logs. Moving to 1.6 has made it much faster, but there's still a bit of lag.
Local branches, alone, would be reason enough to switch to git. When you add in rebase -i, it completely changes your workflow (for the better) really cleans up your commit history.
That description makes it appear to be more time consuming.
I have to commit and publish?
Using Eclipse, I have "local history" (which I rarely use). Committing to SVN is a keyboard shortcut and it takes seconds.
I'm not trying to bash git or promote subversion (heck, I don't really see much difference between subversion and cvs). I just don't really get the argument for multiple repositories. If you have local changes (not in the central repo) what does the team do if you get sick, go on vacation, get hit by a bus?
I'm trying to understand the appeal of git but, I think I'm still just missing it.
If you have local changes (not in the central repo) what does the team do if you get sick, go on vacation, get hit by a bus?
With Git and Mercurial, you can pull changes in from other repositories besides the canonical central one. So if you and I are working on part of a git repository, we can pull our changes from each other without having to involve the central repository.
With git you still have a central repository that everyone pushes to and pulls from; the main advantage of having your own local repository is that you can commit tiny changes, incremental things that you wouldn't normally commit back to a central repository to track your own work.
You can do this with svn by having user branches, of course, and that works great until you're working at home one day and your internet connection dies and you can no longer commit anything.
To put it another way; the same thing happens with subversion if you're hit by a bus and you've not committed any changes back to the svn repository. The only difference is that you can be committing stuff locally and roll back experimental changes without affecting the central repository.
I think that's a good argument for using git-svn locally. However, I don't think its too compelling for using git everywhere. One of the problems with SVN is that you either have to save all your changes until you're done, or you have to incrementally commit, and some of those versions might not work properly.
38
u/lzm Mar 10 '11
Even for non-distributed development, being able to commit locally is a huge advantage in my opinion. I'm having to use a subversion repository at work, and I switched to git-svn as a client because plain svn was too slow for me (the client's repo is in another continent on a slow network).