4 ms·

I go from git to SVN. It's just easier for me to work with and once the team gets used to it, it's a win-win.

by macht 8y ago

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 ago
  If 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 ago
    Most of our team just used Tortoise SVN and the right click -> branch explorer integration. We definitely were not pros at source control.
    - vijucat 8y ago
      Ah, 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 ago
  We 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 ago
  That's because svn merge is much closer to what a git rebase is than what a git merge is.
deleted 8y ago
[deleted]
fwetweyw 8y ago
So as soon as you get a new team, you make them stop using the thing they are comfortable with, so you can use the tool of your choice. Man, that's such a dick move.

I go from git to SVN. It's just easier for me to work with and once the team gets used to it, it's a win-win.

by macht 8y ago

I go from git to SVN. It's just easier for me to work with and once the team gets used to it, it's a win-win.

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 ago
If 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 ago
  Most of our team just used Tortoise SVN and the right click -> branch explorer integration. We definitely were not pros at source control.
  - vijucat 8y ago
    Ah, 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 ago
We 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 ago
That's because svn merge is much closer to what a git rebase is than what a git merge is.

deleted 8y ago

[deleted]

fwetweyw 8y ago

So as soon as you get a new team, you make them stop using the thing they are comfortable with, so you can use the tool of your choice. Man, that's such a dick move.