3 ms·

Number 2 makes me laugh: "Branches are expensive in Subversion - False. A Myth." Totally misses the point that the expense of branching and merging in Subversi

Number 2 makes me laugh: "Branches are expensive in Subversion - False. A Myth." Totally misses the point that the expense of branching and merging in Subversion is all in the UI/UX. Not only is it horribly cumbersome, it's also much easier to get it wrong, not obvious that you are getting it wrong, and harder to recover once you've discovered you've got it wrong.

veli_joza 10y ago
SVN is command line tool, just like Git. Which UI are you talking about? TortoiseSVN? Or are you talking about commands and parameters to svn executable?
- pimlottc 10y ago
  They said UI, not GUI. Command line is still a user interface.
mikestew 10y ago
Cumbersome merging/branching and offline commits are the only two things I need to know to not use SVN (or CVS, Team Foundation Server, et. al.). Maybe I have the git version of Stockholm Syndrome (and after, what, seven or eight years I probably do), but I recall dreading a non-trivial merge, and to a lesser extent branching, in SVN due to cumbersome UI and an easy path to getting it wrong. And if your SCM doesn't let me work on the bus, GTFO.
RJIb8RBYxzAMX9u 10y ago
Would you kindly clarify? Branching and merging in svn seems perfectly obvious to me: $ cd trunk-wc $ svn cp ^/trunk ^/branches/my-topic # create my-topic branch $ svn switch ^/branches/my-topic # switch working copy to my-topic $ # Hack away $ svn commit -m "My awesome new feature." $ svn switch ^/trunk # switch working copy to trunk $ svn merge ^/branches/my-topic ^/trunk # merge topic branch changes to trunk (a) $ svn commit -m "Merge awesome feature from my-topic." In step (a), resolve any conflicting files with svn resolve; to start over, do svn revert [-R] (granted, new files will be left behind and there's no git clean equivalent AFAIK). With the exception of svn cp, all the commands are self-describing (and with svn cp, someone argued in the BK open-sourcing thread that "a branch is a copy" model is fairly intuitive for even non-technical users). I concede that git is more powerful and supports different branch / merge workflows than svn, but svn's hardly horrible.
- jammycakes 10y ago
  If you stick to the rules, and you have only one branches/tags/trunk structure in your repo, and you actually set up the branches/tags/trunk structure in the first place, yes. But my whole point is that there's far too much scope to get it wrong in ways that can be difficult to fix. If you have multiple projects in your repo, svn cp and svn switch become cumbersome. Many people check out the root folder with the entire structure and all the branches, and not just trunk. I've seen projects that have nested branches/tags/trunk structures. I've seen people check code in to two branches at once. I've seen people "branch" by physically copying the files client-side then checking in the result. Losing the relationship between the branches that they need to merge successfully. If you check in the merge then find you've messed it up, you can't roll back and start over without cluttering up your source history. And even then, how to do that is non-obvious and easy to get wrong. And people DO make these mistakes repeatedly because svn treats branching and merging as an advanced technique. The first several times you do it, you invariably mess up, and leave a permanent record of how you messed up. Very often it's not you who learns that you've messed up but a colleague who does the merge. And once you learn to get it right, someone else on your team comes along and they get it wrong. The feedback loop is terrible. Whereas with git it's a core competency so you learn you've messed up fairly quickly. And offline commits let you easily roll back when you do. The feedback loop is rapid and effective.

veli_joza 10y ago

SVN is command line tool, just like Git. Which UI are you talking about? TortoiseSVN? Or are you talking about commands and parameters to svn executable?

pimlottc 10y ago
They said UI, not GUI. Command line is still a user interface.

mikestew 10y ago

Cumbersome merging/branching and offline commits are the only two things I need to know to not use SVN (or CVS, Team Foundation Server, et. al.). Maybe I have the git version of Stockholm Syndrome (and after, what, seven or eight years I probably do), but I recall dreading a non-trivial merge, and to a lesser extent branching, in SVN due to cumbersome UI and an easy path to getting it wrong. And if your SCM doesn't let me work on the bus, GTFO.

RJIb8RBYxzAMX9u 10y ago

Would you kindly clarify? Branching and merging in svn seems perfectly obvious to me: $ cd trunk-wc $ svn cp ^/trunk ^/branches/my-topic # create my-topic branch $ svn switch ^/branches/my-topic # switch working copy to my-topic $ # Hack away $ svn commit -m "My awesome new feature." $ svn switch ^/trunk # switch working copy to trunk $ svn merge ^/branches/my-topic ^/trunk # merge topic branch changes to trunk (a) $ svn commit -m "Merge awesome feature from my-topic." In step (a), resolve any conflicting files with svn resolve; to start over, do svn revert [-R] (granted, new files will be left behind and there's no git clean equivalent AFAIK). With the exception of svn cp, all the commands are self-describing (and with svn cp, someone argued in the BK open-sourcing thread that "a branch is a copy" model is fairly intuitive for even non-technical users). I concede that git is more powerful and supports different branch / merge workflows than svn, but svn's hardly horrible.

jammycakes 10y ago
If you stick to the rules, and you have only one branches/tags/trunk structure in your repo, and you actually set up the branches/tags/trunk structure in the first place, yes. But my whole point is that there's far too much scope to get it wrong in ways that can be difficult to fix. If you have multiple projects in your repo, svn cp and svn switch become cumbersome. Many people check out the root folder with the entire structure and all the branches, and not just trunk. I've seen projects that have nested branches/tags/trunk structures. I've seen people check code in to two branches at once. I've seen people "branch" by physically copying the files client-side then checking in the result. Losing the relationship between the branches that they need to merge successfully. If you check in the merge then find you've messed it up, you can't roll back and start over without cluttering up your source history. And even then, how to do that is non-obvious and easy to get wrong. And people DO make these mistakes repeatedly because svn treats branching and merging as an advanced technique. The first several times you do it, you invariably mess up, and leave a permanent record of how you messed up. Very often it's not you who learns that you've messed up but a colleague who does the merge. And once you learn to get it right, someone else on your team comes along and they get it wrong. The feedback loop is terrible. Whereas with git it's a core competency so you learn you've messed up fairly quickly. And offline commits let you easily roll back when you do. The feedback loop is rapid and effective.