3 ms·

I agree with the main thesis. But I wonder about: > Subversion makes branching and merging so clunky, user-unfriendly and error-prone that it simply isn’t pra

by bmm6o 11y ago

I agree with the main thesis. But I wonder about: > Subversion makes branching and merging so clunky, user-unfriendly and error-prone that it simply isn’t practical Is this really a technical problem, or is it more cultural? I'm not very familiar with Git... is there really something there that makes this fundamentally easier?

Pfhreak 11y ago
Git branching is fast and very simple. A 'git checkout -b FOO' and you've got one made. You can flip back and forth between branches with a single command as well, which makes very easy to set up experiments (say you wanted to profile a couple different prototypes), or you are working on three different new features at the same time. Branches are also very easy to move around the revision history. If I created a branch 3 months ago, and I wanted to go back and pull that back onto mainline, I can easy 'rebase' those changes as if I created the branch off of the most recent commit. Again, it's a single command that, barring merge conflicts, just works. Branches can also be pushed and pulled from one machine to another. Got started working on a feature, but can't finish it in this sprint? Have a coworker pull that branch to their box and pick it up. Made an experimental change? Push that branch back to the server so others can take a look. Git branching absolutely changed the way I write code. I create branches all the time, because they are so cheap I can use them to mess around with small changes without worrying about messing up mainline or my current feature branches.
yincrash 11y ago
This stackoverflow post is just for you! http://stackoverflow.com/questions/19333088/how-is-svn-v-1-8-branching-merging-compared-to-git http://stackoverflow.com/questions/19333088/how-is-svn-v-1-8...
jsolson 11y ago
It was, historically, definitely a technical problem. You had to know what the base changelist for a branch was in order to integrate into it from trunk or to merge it back into trunk cleanly. I believe these problems may now have been fixed, but I haven't used svn in so long that I can't say for sure. Regardless, branching and merging in git were designed to be straightforward from the outset. Due to the nature of git's commit graph it is straightforward to tell (with appropriate tools, and this is somewhere that git suffered initially but has improved dramatically as its popularity has waxed) where in history a branch was created and which commits are being merged. If you want a branch and merge workflow where branches are used frequently and merges are the mechanism by which changes arrive in 'trunk' (which is basically how the Linux kernel is maintained with Linus being the final integrator -- he merges branches from what are effectively lieutenants who act as integrators for their respective subsystems) then git makes this workflow very straightforward.
aidenn0 11y ago
Some of this is historical. I started using subversion at 1.3 and merge tracking didn't exist at all until 1.5; we just upgraded to 1.8 at work and it's much smarter, though it does still lag behind git a bit.

by bmm6o 11y ago

Pfhreak 11y ago

Git branching is fast and very simple. A 'git checkout -b FOO' and you've got one made. You can flip back and forth between branches with a single command as well, which makes very easy to set up experiments (say you wanted to profile a couple different prototypes), or you are working on three different new features at the same time. Branches are also very easy to move around the revision history. If I created a branch 3 months ago, and I wanted to go back and pull that back onto mainline, I can easy 'rebase' those changes as if I created the branch off of the most recent commit. Again, it's a single command that, barring merge conflicts, just works. Branches can also be pushed and pulled from one machine to another. Got started working on a feature, but can't finish it in this sprint? Have a coworker pull that branch to their box and pick it up. Made an experimental change? Push that branch back to the server so others can take a look. Git branching absolutely changed the way I write code. I create branches all the time, because they are so cheap I can use them to mess around with small changes without worrying about messing up mainline or my current feature branches.

yincrash 11y ago

This stackoverflow post is just for you! http://stackoverflow.com/questions/19333088/how-is-svn-v-1-8-branching-merging-compared-to-git http://stackoverflow.com/questions/19333088/how-is-svn-v-1-8...

jsolson 11y ago

It was, historically, definitely a technical problem. You had to know what the base changelist for a branch was in order to integrate into it from trunk or to merge it back into trunk cleanly. I believe these problems may now have been fixed, but I haven't used svn in so long that I can't say for sure. Regardless, branching and merging in git were designed to be straightforward from the outset. Due to the nature of git's commit graph it is straightforward to tell (with appropriate tools, and this is somewhere that git suffered initially but has improved dramatically as its popularity has waxed) where in history a branch was created and which commits are being merged. If you want a branch and merge workflow where branches are used frequently and merges are the mechanism by which changes arrive in 'trunk' (which is basically how the Linux kernel is maintained with Linus being the final integrator -- he merges branches from what are effectively lieutenants who act as integrators for their respective subsystems) then git makes this workflow very straightforward.

aidenn0 11y ago

Some of this is historical. I started using subversion at 1.3 and merge tracking didn't exist at all until 1.5; we just upgraded to 1.8 at work and it's much smarter, though it does still lag behind git a bit.