4 ms·

Show HN: SVN Branching as easy as Git

14 points by grexi 13y ago

HugoDias 13y ago
One question: Why?
- grexi 13y ago
  If you have large SVN repositories in production, it's often not easy to switch to git. But you'll get some comfort back with those aliases :-)
  - ramses0 13y ago
    I have a 1.4gb SVN repo (working copy checkout, so more like 700mb actual files) with 15k revisions. Horror of horrors, I pulled up the first commit message and look what message I found: commit ... Author: (no author) (no author)@... Date: Sun Jun 8 ... 2003 +0000 Standard project directories initialized by cvs2svn. git-svn-id: ...@1 ... If you've got more than 15k revisions, larger than 1.4gb working directory, or a codebase that is over 10 years old then keep talking. Otherwise get over yourself and use git-svn.
    - unsigner 13y ago
      170k revisions and several repositories totalling half a TB, with some working directories in the high double digit GBs. Given that we have no performance or reliability problems, and our server isn't particularly beefy - just problems with branching - I wouldn't be surprised if people have an order of magnitude larger repos. (Game development shop with art assets in SVN)
      - mpyne 13y ago
        The KDE Subversion repository had modules with upwards of a million revisions. Most have been moved to git, and had to be split into much more granular git modules (though technical concerns were not the only reason that was done, we wanted more modularity anyways).
  - grexi 13y ago
    Btw by large SVN repositories I also mean "many devs with checked out working copies" and "many devs which know their workflow reasonable well". The conversion tools work well, but bringing 200 devs to a new system can be a major PITA.
chrismorgan 13y ago
This is one region where Mercurial particularly shines: things like hg-git and hgsubversion. I believe hgsubversion even supports translating from hg branches to svn branches. (Git's model is restricted enough that it can't very successfully act as an interface for Mercurial or Subversion. Mercurial can do both very well.) I had to use an SVN repository this semester at Uni. Only once did I actually check it out in SVN—then I decided to chuck that and use hgsubversion. That made me considerably more productive than the other students... especially when the SVN server ran out of disk space: I could still commit and push later, while they had to wait. :-) When I have to deal with Git repositories, I typically use Mercurial, also.
grexi 13y ago
And look, the irony, I've added my aliases on github. I'm no brain dead svn fanboy.

14 points by grexi 13y ago

HugoDias 13y ago

One question: Why?

grexi 13y ago
If you have large SVN repositories in production, it's often not easy to switch to git. But you'll get some comfort back with those aliases :-)
- ramses0 13y ago
  I have a 1.4gb SVN repo (working copy checkout, so more like 700mb actual files) with 15k revisions. Horror of horrors, I pulled up the first commit message and look what message I found: commit ... Author: (no author) (no author)@... Date: Sun Jun 8 ... 2003 +0000 Standard project directories initialized by cvs2svn. git-svn-id: ...@1 ... If you've got more than 15k revisions, larger than 1.4gb working directory, or a codebase that is over 10 years old then keep talking. Otherwise get over yourself and use git-svn.
  - unsigner 13y ago
    170k revisions and several repositories totalling half a TB, with some working directories in the high double digit GBs. Given that we have no performance or reliability problems, and our server isn't particularly beefy - just problems with branching - I wouldn't be surprised if people have an order of magnitude larger repos. (Game development shop with art assets in SVN)
    - mpyne 13y ago
      The KDE Subversion repository had modules with upwards of a million revisions. Most have been moved to git, and had to be split into much more granular git modules (though technical concerns were not the only reason that was done, we wanted more modularity anyways).
- grexi 13y ago
  Btw by large SVN repositories I also mean "many devs with checked out working copies" and "many devs which know their workflow reasonable well". The conversion tools work well, but bringing 200 devs to a new system can be a major PITA.

chrismorgan 13y ago

This is one region where Mercurial particularly shines: things like hg-git and hgsubversion. I believe hgsubversion even supports translating from hg branches to svn branches. (Git's model is restricted enough that it can't very successfully act as an interface for Mercurial or Subversion. Mercurial can do both very well.) I had to use an SVN repository this semester at Uni. Only once did I actually check it out in SVN—then I decided to chuck that and use hgsubversion. That made me considerably more productive than the other students... especially when the SVN server ran out of disk space: I could still commit and push later, while they had to wait. :-) When I have to deal with Git repositories, I typically use Mercurial, also.

grexi 13y ago

And look, the irony, I've added my aliases on github. I'm no brain dead svn fanboy.