3 ms·
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
by 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 agoThose 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 agoSource Depot, a fork of Perforce.
- alkonaut 6y agoYeah 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.