You can do the same thing with a personal branch in SVN. There was sort of a competing line of thought that keeping it local is a bit of "cave-hiding" behavior.
http://blog.red-bean.com/sussman/?p=20
While there may be some equivalent in SVN, it gives you nowhere near the flexibility. I can't for example, create an idea branch for one feature I'm working on, try another idea on another branch, delete the first branch, switch back to the second, create another branch off of that and stop midway to checkout master (trunk) to work on something urgent and the then continue development and merge back into master when I'm done.
The equivalent in svn would make me groan, for complexity and for the performance.
Also, the same rules apply when 'cave-hiding'. You should still be committing early and often, but in gitland, 'committing' really means syncing up with an authoritative repo. You can 'cave-hide' in svn by just not committing anything and keeping your changes in your local working copy.
Agree on 'cave-hiding' being just as possible in svn as git, but I disagree that your workflow is particularly complicated or poorly performing in svn.
Creating branches in svn is cheap, switching branches is cheap, checking out a new working copy if you want to work on two changes at once is also cheap, merging is cheap. There's no reason not to do what you're suggesting in svn.
One of the things that git does better than svn is merging branches when files have moved, but I don't think your use case addresses this directly. Git does some things better than svn, but svn does a good enough job that you have to be a little careful when making the case against it.
> Creating branches in svn is cheap, switching branches is cheap, checking out a new working copy if you want to work on two changes at once is also cheap, merging is cheap.
I think then the problem is our definitions of 'cheap'.
A typical switch command on a working copy of our codebase at work (20,000 + files) takes 1-2 minutes, and its a lot longer for creating a new branch. In a git version of the same repository both these operations are comparatively instantaneous. YMMV.
Also, regarding merging, I believe that in new versions of the svn client there is mergeinfo, however older repositories without this metadata will give you issues when you for example create a branch, merge changes from trunk into your branch and then subsequently attempt to merge that branch back into trunk.
This is the classic 'svn sucks at merging' problem and to me, its complexity overhead that would deter me from branching, i.e. not 'cheap'. I normally get around this by remembering the revision number of the last 'rebase' from trunk (or give it an easily greppable commit message) and then when I do the merge back into trunk I specify that I only want changes from the last rebase to HEAD.
The internal model of git makes this a non-issue, i.e. each commit has a parent commit, and for any given commit on two separate branches, git just walks the tree up to the nearest common ancestor.
Any version from 1.5, which was released in June 2008, has merge tracking. If you're using svn and don't understand how mergeinfo works, then you're not in a position to make a fair comparison on merging. A lot of the comparisons between svn and git/hg/etc. are made by people who don't seem to understand recent versions of svn well.
Yes, old versions of svn "suck at merging", but the workflows with merges between multiple branches you describe work well in modern versions of svn with merge tracking. Your "remembering the revision number of the last 'rebase'" is unnecessary in modern svn.
I grant you that switch can take a while on a large code base, as can a checkout of a new working copy. Creating a new branch is contrary to what you say instantaneous in svn due to the cheap copies, however getting that new branch in a new working copy to work on I admit might take a while. A large part of this problem is mitigated if you just have multiple working copies checked out, but not all.
The details on why branching is cheap in svn are described here:
Part of the problem with svn is that the model is too flexible compared to git: the merge tracking supports tracking partial merges between branches, which is arguably an unnecessary complexity - the svn developers have expressed concern about whether this feature is valuable given the complexity it adds.
For general merge scenarios if you're using mergeinfo correctly, follow the practices laid out in the svn book, you shouldn't find merging particularly difficult or expensive in svn, even if you're doing relatively complicated workflows.
I'm not saying this is easier or works better than svn than git, just that it's doable and not as bad as many people make out. The merging in svn is (too) complex, but once you figure out how it works then it works well. With your "I believe...there is mergeinfo" and loewenskind's "I've done it. Once." I get the impression that neither of you have put the time in to really figure out how it works, but are still arguing against it.
Personally I prefer the way git works. But as someone who uses it everyday, for scenarios like the ones you say are nightmares, I don't think svn is as bad as you make out. There is an argument to be made for using git, but neither you, loewenskind nor the article make it as well as you could.
>Creating branches in svn is cheap, switching branches is cheap, checking out a new working copy if you want to work on two changes at once is also cheap, merging is cheap.
This is just misinformation. Merging is absolutely not cheap, how incredibly expensive it is in SVN is the reason some of the DVCSes of today even exist. Try doing some of the common Git work flows [1] in SVN and let us know how well that works out. I've done it. Once. After that we adopted a methodology to ensure we'd never have to do it again.
[1] Pretty much anything where you are moving change sets between multiple branches before pushing back to main. Trivial in a DVCS, a nightmare in SVN.
Comments
You can do the same thing with a personal branch in SVN. There was sort of a competing line of thought that keeping it local is a bit of "cave-hiding" behavior. http://blog.red-bean.com/sussman/?p=20
While there may be some equivalent in SVN, it gives you nowhere near the flexibility. I can't for example, create an idea branch for one feature I'm working on, try another idea on another branch, delete the first branch, switch back to the second, create another branch off of that and stop midway to checkout master (trunk) to work on something urgent and the then continue development and merge back into master when I'm done.
The equivalent in svn would make me groan, for complexity and for the performance.
Also, the same rules apply when 'cave-hiding'. You should still be committing early and often, but in gitland, 'committing' really means syncing up with an authoritative repo. You can 'cave-hide' in svn by just not committing anything and keeping your changes in your local working copy.
Agree on 'cave-hiding' being just as possible in svn as git, but I disagree that your workflow is particularly complicated or poorly performing in svn.
Creating branches in svn is cheap, switching branches is cheap, checking out a new working copy if you want to work on two changes at once is also cheap, merging is cheap. There's no reason not to do what you're suggesting in svn.
One of the things that git does better than svn is merging branches when files have moved, but I don't think your use case addresses this directly. Git does some things better than svn, but svn does a good enough job that you have to be a little careful when making the case against it.
> Creating branches in svn is cheap, switching branches is cheap, checking out a new working copy if you want to work on two changes at once is also cheap, merging is cheap.
I think then the problem is our definitions of 'cheap'.
A typical switch command on a working copy of our codebase at work (20,000 + files) takes 1-2 minutes, and its a lot longer for creating a new branch. In a git version of the same repository both these operations are comparatively instantaneous. YMMV.
Also, regarding merging, I believe that in new versions of the svn client there is mergeinfo, however older repositories without this metadata will give you issues when you for example create a branch, merge changes from trunk into your branch and then subsequently attempt to merge that branch back into trunk.
This is the classic 'svn sucks at merging' problem and to me, its complexity overhead that would deter me from branching, i.e. not 'cheap'. I normally get around this by remembering the revision number of the last 'rebase' from trunk (or give it an easily greppable commit message) and then when I do the merge back into trunk I specify that I only want changes from the last rebase to HEAD.
The internal model of git makes this a non-issue, i.e. each commit has a parent commit, and for any given commit on two separate branches, git just walks the tree up to the nearest common ancestor.
Any version from 1.5, which was released in June 2008, has merge tracking. If you're using svn and don't understand how mergeinfo works, then you're not in a position to make a fair comparison on merging. A lot of the comparisons between svn and git/hg/etc. are made by people who don't seem to understand recent versions of svn well.
Yes, old versions of svn "suck at merging", but the workflows with merges between multiple branches you describe work well in modern versions of svn with merge tracking. Your "remembering the revision number of the last 'rebase'" is unnecessary in modern svn.
I grant you that switch can take a while on a large code base, as can a checkout of a new working copy. Creating a new branch is contrary to what you say instantaneous in svn due to the cheap copies, however getting that new branch in a new working copy to work on I admit might take a while. A large part of this problem is mitigated if you just have multiple working copies checked out, but not all.
The details on why branching is cheap in svn are described here:
http://svn.apache.org/repos/asf/subversion/trunk/notes/subve...
Part of the problem with svn is that the model is too flexible compared to git: the merge tracking supports tracking partial merges between branches, which is arguably an unnecessary complexity - the svn developers have expressed concern about whether this feature is valuable given the complexity it adds.
For general merge scenarios if you're using mergeinfo correctly, follow the practices laid out in the svn book, you shouldn't find merging particularly difficult or expensive in svn, even if you're doing relatively complicated workflows.
I'm not saying this is easier or works better than svn than git, just that it's doable and not as bad as many people make out. The merging in svn is (too) complex, but once you figure out how it works then it works well. With your "I believe...there is mergeinfo" and loewenskind's "I've done it. Once." I get the impression that neither of you have put the time in to really figure out how it works, but are still arguing against it.
Personally I prefer the way git works. But as someone who uses it everyday, for scenarios like the ones you say are nightmares, I don't think svn is as bad as you make out. There is an argument to be made for using git, but neither you, loewenskind nor the article make it as well as you could.
>Creating branches in svn is cheap, switching branches is cheap, checking out a new working copy if you want to work on two changes at once is also cheap, merging is cheap.
This is just misinformation. Merging is absolutely not cheap, how incredibly expensive it is in SVN is the reason some of the DVCSes of today even exist. Try doing some of the common Git work flows [1] in SVN and let us know how well that works out. I've done it. Once. After that we adopted a methodology to ensure we'd never have to do it again.
[1] Pretty much anything where you are moving change sets between multiple branches before pushing back to main. Trivial in a DVCS, a nightmare in SVN.