3 ms·
SVN is really heavyweight for branches and tags. It used to take like a minute to branch with SVN but when we swapped to git it took like less than a blink. Al
by aetherspawn 8y ago
SVN is really heavyweight for branches and tags. It used to take like a minute to branch with SVN but when we swapped to git it took like less than a blink.
Also —rebase is way better than merge. I haven’t had to merge git for over 6 months but with SVN I was doing it twice daily, at least.
- vijucat 8y agoIf you use a repository URL rather than a local filename / dirname in svn copy, it's a purely remote copy and is instantaneous: $ svn copy file:///var/svn/repos/test/dir1 \ file:///var/svn/repos/test/dir1_jira_1886 -m "For bugfix to SERV-1886" http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.htm... https://svnvsgit.com/ https://svnvsgit.com/
- aetherspawn 8y agoMost of our team just used Tortoise SVN and the right click -> branch explorer integration. We definitely were not pros at source control.
- vijucat 8y agoAh, I see! Tortoise SVN is great for the scenario where business users can learn and use revision control, too, but I guess once you're doing branching using Tortoise SVN, you're in a weird territory where you're pro, but not to the extent you're ready to use the command line...
- isostatic 8y agoWe used to have a large (>20GB) svn repository, I never noticed tags (which was part of the build process) taking any time, certainly sub-second. However the branching process in svn is a right pain, if you work in branches. Depends on what your code is if you need the overhead and risk of branches I guess.
- xorcist 8y agoThat's because svn merge is much closer to what a git rebase is than what a git merge is.