If you stick to the rules, <i>and</i> you have only one branches&#x2F;tags&#x2F;trunk structure in your repo, <i>and</i> you actually set up the branches&#x2F;tags&#x2F;trunk structure in the first place, yes.<p>But my whole point is that there&#x27;s far too much scope to get it wrong in ways that can be difficult to fix.<p>If you have multiple projects in your repo, svn cp and svn switch become cumbersome.<p>Many people check out the root folder with the entire structure and all the branches, and not just trunk.<p>I&#x27;ve seen projects that have nested branches&#x2F;tags&#x2F;trunk structures.<p>I&#x27;ve seen people check code in to two branches at once.<p>I&#x27;ve seen people &quot;branch&quot; by physically copying the files client-side then checking in the result. Losing the relationship between the branches that they need to merge successfully.<p>If you check in the merge then find you&#x27;ve messed it up, you can&#x27;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.<p>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&#x27;s not you who learns that you&#x27;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.<p>Whereas with git it&#x27;s a core competency so you learn you&#x27;ve messed up fairly quickly. And offline commits let you easily roll back when you do. The feedback loop is rapid and effective.