4 ms·

I think you're missing the point. In your workflow, you create the branch before you started work on your new feature. In my Git example, I created the branch r

I think you're missing the point. In your workflow, you create the branch before you started work on your new feature. In my Git example, I created the branch retroactively. If you were to attempt the same feat in SVN, it would get a little messy. You'd have to first roll back the repo: svn merge -r HEAD:96 http://server/my_repo svn commit -m "Reverted last 4 commits" Then create the branch and merge in the previous commit: svn copy ./my_code ./my_new_feature svn merge http://server/my_repo/my_code@100 my_new_feature svn commit -m "Imported reverted commits to new_feature" Then make your changes: svn commit -m "Fixed bug" Then merge your change into the new branch: cd ../new_feature svn merge -c HEAD ../my_code svn commit -m "Merged bug fix" And once you've done all that, your commit history looks like: A B C D Reverted last 4 commits Imported reverted commits to new_feature Fixed bug Merged bug fix Whilst in Git: Fixed bug <- master A B C D <- new_feature Now, obviously you'd never actually do all this in SVN if you were sensible, but that's exactly my point. The Git concept of a branch being a reference to a commit is more flexible than the SVN idea of a branch being akin to a directory. Things that are perfectly natural to do in Git are rather more complex to do in SVN, and leave behind a messy history of merges.

timr 18y ago
I'm not missing the point -- I'm saying that your point is silly. You're fixated on doing everything in the same directory, when in fact it's far easier not to do it that way, and the only argument you're making for doing it that way, is that it's more "flexible". But flexibility is not a virtue, unless you need the flexibility! "obviously you'd never actually do all this in SVN if you were sensible" Exactly. You'd never do it. You don't need to do it. You can get the job done without doing it. And that's what matters. Git fanboys are hilarious sometimes...every argument is made from the position that none of the rest of us really understand git, and that if only we did, we'd fall in love with git in all of it's fiddly glory. What they miss is that many of us hate complexity, and we avoid complexity that doesn't justify itself with true functional advantages. I like simple tools that get the job done. Git makes my life harder; I have to think about more things to do the same, basic tasks that were made trivially easy in subversion. That's the point.
- weavejester 18y ago
  I'm not claiming that Git is better than Subversion, or that you should use it. I'm merely pointing out that branches in Git have other advantages as well as being faster. The fundamental problem with Subversion branches, at least in my view, is that you have to know ahead of time that you want a branch. Perhaps this isn't a problem for you, but it is for me. Sometimes I find myself thinking, "Hang on, is this really the right way to solve this problem?" In Git, I can save my current work in a branch, trot back a few revisions, and try a different approach. In contrast, Subversion encourages a largely linear style of development. I expect some people, like yourself, prefer this approach, finding it conceptually simpler. And that's fine; I'm not saying that's wrong or bad, or that you should stop using Subversion. That's clearly what you're most comfortable with. But a linear development model isn't for everyone. Those of us who like to experiment and backtrack tend to develop in a tree-like fashion, branching off shoots all over the place and pruning the ones that turn out to be a dead end. For this style of development, Git's branching model is significantly better than Subversion's.

timr 18y ago

I'm not missing the point -- I'm saying that your point is silly. You're fixated on doing everything in the same directory, when in fact it's far easier not to do it that way, and the only argument you're making for doing it that way, is that it's more "flexible". But flexibility is not a virtue, unless you need the flexibility! "obviously you'd never actually do all this in SVN if you were sensible" Exactly. You'd never do it. You don't need to do it. You can get the job done without doing it. And that's what matters. Git fanboys are hilarious sometimes...every argument is made from the position that none of the rest of us really understand git, and that if only we did, we'd fall in love with git in all of it's fiddly glory. What they miss is that many of us hate complexity, and we avoid complexity that doesn't justify itself with true functional advantages. I like simple tools that get the job done. Git makes my life harder; I have to think about more things to do the same, basic tasks that were made trivially easy in subversion. That's the point.

weavejester 18y ago
I'm not claiming that Git is better than Subversion, or that you should use it. I'm merely pointing out that branches in Git have other advantages as well as being faster. The fundamental problem with Subversion branches, at least in my view, is that you have to know ahead of time that you want a branch. Perhaps this isn't a problem for you, but it is for me. Sometimes I find myself thinking, "Hang on, is this really the right way to solve this problem?" In Git, I can save my current work in a branch, trot back a few revisions, and try a different approach. In contrast, Subversion encourages a largely linear style of development. I expect some people, like yourself, prefer this approach, finding it conceptually simpler. And that's fine; I'm not saying that's wrong or bad, or that you should stop using Subversion. That's clearly what you're most comfortable with. But a linear development model isn't for everyone. Those of us who like to experiment and backtrack tend to develop in a tree-like fashion, branching off shoots all over the place and pruning the ones that turn out to be a dead end. For this style of development, Git's branching model is significantly better than Subversion's.