17 ms·
> The KDE team spent a lot of time just developing the tools required to do it KDE was a special case because we wanted to split a monorepo into one repo per a
by majewsky 9y ago
> The KDE team spent a lot of time just developing the tools required to do it
KDE was a special case because we wanted to split a monorepo into one repo per application at the same time, yet retain as much history as possible (including across restructurings of the source tree). Also, the massive size of the monorepo (about 1.5 million revisions) made it infeasible to use the standard tooling of git-svn to do it.
Most projects will not have these problems. At work, I migrated a rather large application (~500k LOC) from SVN to Git while retaining the entire history, with the standard tooling (`git svn clone && git push`, basically).
- alkonaut 9y agoOurs isn’t even very large, I’d call it “medium”. The svn working copy is around 2GB and the entire 100krev history is about 80Gb. This is easy to handle centralized but we obviously need LFS or GVFS for it to be feasible in Git (keeping all the binary assets AND the 100k rev history is a requirement). Migrating it using git svn is a couple of days (and annoying when it stops half way because of some issue) At least with svn2git we can test-convert including lfs migration in just a couple of hours.
- majewsky 9y agoAh yeah, repos with (a large number of) large binary files are a different story. I'm usually dealing with code only (and maybe some bitmaps for UIs).