3 ms·

Our company will never transition from SVN to Git because the transition tools fail on our ancient SVN repo. Learn from us: switch now because switching later m

Our company will never transition from SVN to Git because the transition tools fail on our ancient SVN repo. Learn from us: switch now because switching later may not be an option.

deleted 6y ago
[deleted]
alkonaut 6y ago
I migrated a 100k (20 years, 100Gb history) revision 20Gb workingcopy svn repo with full history and it was pretty painful. But in the end, so long as you can check out any revision (i.e. the repo is functional) then migration should also work, as should updating the repo format to the latest svn repo format. I assume the upgrade to a recent svn format is what's blocking? Even so, worst case it should theoretically be possible to do a looped checkout+commit from svn to git. Metadata such as commit dates can be rewritten later if needed.
- Arnavion 6y ago
  You could also just keep the SVN repo around for its commit history and start a new git repo with the trunk imported without history. Sure you'll have to switch back and forth between the two repos for history, but over time it'll become less and less necessary. Microsoft has done this for many long-lived repos; Windows and SQL Server are the two famous examples, with multiple such transitions.
  - christophilus 6y ago
    Those weren’t using SVN, though, I don’t think. I can’t remember the name of the version control system they used, but it was some custom license of a proprietary system. Clear-case, maybe? Anyway, it was a nuisance, and I imagine the move to git was both a money saver and ultimately (once all of the migration pain and missing capabilities had been addressed) a nicer dev experience.
    - Arnavion 6y ago
      Source Depot, a fork of Perforce.
  - alkonaut 6y ago
    Yeah we decided against it and kept the history. Since the size grows quicker and quicker in an expanding team, cutting history e.g. to half would just cut a few percent of the size. It actually works surprisingly well with git lfs now. Operations are quick enough and so long as you use persistent CI severs (so they never have to clone from scratch) builds aren't affected by the size either.
jankotek 6y ago
Brute force it; write a script to checkout every revision from SVN, checkin into git.

Our company will never transition from SVN to Git because the transition tools fail on our ancient SVN repo. Learn from us: switch now because switching later may not be an option.

deleted 6y ago

[deleted]

alkonaut 6y ago

I migrated a 100k (20 years, 100Gb history) revision 20Gb workingcopy svn repo with full history and it was pretty painful. But in the end, so long as you can check out any revision (i.e. the repo is functional) then migration should also work, as should updating the repo format to the latest svn repo format. I assume the upgrade to a recent svn format is what's blocking? Even so, worst case it should theoretically be possible to do a looped checkout+commit from svn to git. Metadata such as commit dates can be rewritten later if needed.

Arnavion 6y ago
You could also just keep the SVN repo around for its commit history and start a new git repo with the trunk imported without history. Sure you'll have to switch back and forth between the two repos for history, but over time it'll become less and less necessary. Microsoft has done this for many long-lived repos; Windows and SQL Server are the two famous examples, with multiple such transitions.
- christophilus 6y ago
  Those weren’t using SVN, though, I don’t think. I can’t remember the name of the version control system they used, but it was some custom license of a proprietary system. Clear-case, maybe? Anyway, it was a nuisance, and I imagine the move to git was both a money saver and ultimately (once all of the migration pain and missing capabilities had been addressed) a nicer dev experience.
  - Arnavion 6y ago
    Source Depot, a fork of Perforce.
- alkonaut 6y ago
  Yeah we decided against it and kept the history. Since the size grows quicker and quicker in an expanding team, cutting history e.g. to half would just cut a few percent of the size. It actually works surprisingly well with git lfs now. Operations are quick enough and so long as you use persistent CI severs (so they never have to clone from scratch) builds aren't affected by the size either.

jankotek 6y ago

Brute force it; write a script to checkout every revision from SVN, checkin into git.