This presentation provides 2 examples of a migration from SVN to git and then provides pros and cons of splitting (or not) the SVN repository when migrating to git. This presentation was done for human talks, Grenoble, France

1. svn to Git: to split or not to split a repo ?
Dominique Dumont
Debian Project
Oct 2018
Dominique Dumont svn to Git: to split or not to split a repo ?

2. Svn to Git: Debian-perl example
Old situation:
one repo for ~ 3000 source package of Perl modules
all these modules are independent and have a different life
cycle
Migration:
did not even consider mono repo
need to synchronize migration with devs around the world
had to update team monitoring tool
Debian-perl team members had to use new build tools
no impact on Debian builder (insulated by package source) or
Bug tracker (refers to package source and not on repo)
Dominique Dumont svn to Git: to split or not to split a repo ?

3. Svn to Git: Debian-perl example
Old situation:
one repo for ~ 3000 source package of Perl modules
all these modules are independent and have a different life
cycle
Migration:
did not even consider mono repo
need to synchronize migration with devs around the world
had to update team monitoring tool
Debian-perl team members had to use new build tools
no impact on Debian builder (insulated by package source) or
Bug tracker (refers to package source and not on repo)
Dominique Dumont svn to Git: to split or not to split a repo ?

4. Svn to Git: config-model example
Old situation:
one repo for 3 more or less dependent components
mono repo with SVN was more convenient (and traditional)
one core component is a dependency of all other components.
No dependency cycles though
integration is managed by Perl package manager (cpan) or
downstream package
Migration:
First done on mono repo (easier migration)
pb: tags apply to all components. Need convention on tags
(e.g. ”tkui_v0.124”).
Turns out components had different life cycles and loose
dependencies
ended up splitting the mono git repo into multiple git repo
(kept history with git filter-branch)
Dominique Dumont svn to Git: to split or not to split a repo ?

5. Svn to Git: config-model example
Old situation:
one repo for 3 more or less dependent components
mono repo with SVN was more convenient (and traditional)
one core component is a dependency of all other components.
No dependency cycles though
integration is managed by Perl package manager (cpan) or
downstream package
Migration:
First done on mono repo (easier migration)
pb: tags apply to all components. Need convention on tags
(e.g. ”tkui_v0.124”).
Turns out components had different life cycles and loose
dependencies
ended up splitting the mono git repo into multiple git repo
(kept history with git filter-branch)
Dominique Dumont svn to Git: to split or not to split a repo ?

6. Svn to Git: pros and cons of mono repo
one repository to manage (does it scale ?)
good when components are strongly coupled (which
may hint at design problems)
git clone downloads the whole history (can be quite
big for mono repo)
history analysis is more difficult
need to deal with unrelated commits when rebasing
git tag: only way to track released versions. No way
to tag a part of a repo like in SVN. Often worked
around by applying prefix to tags.
Cannot practically drop an obsolete project. Dead
projects stay in repo history.
Dominique Dumont svn to Git: to split or not to split a repo ?

7. Svn to Git: pros and cons of multi repo
easier to manage with several teams
better adapted to manage components with different
life cycles
Component integration is done at a later stage:
components must be built and distributed (many
choices: distro packages, npm, jar, images) through a
repository (debian, joyent, nexus, docker registry,
CPAN...)
Dominique Dumont svn to Git: to split or not to split a repo ?

8. Git: hybrid mono/multi repo
Some projects (docker, moarvm, rakudo-star) adopt a hybrid
solution: several repos are gathered together:
git submodule
git subtree
git subrepo
Pros and Cons
no need to create or distribute build artifacts
can be confusing when working in the main repo
(what happen when git pushing from a dependency ?
branches vs subrepo ?)
outside of the repo, no easy way to track the version
of the imported dependency (e.g. match CVE with
version of a dependency)
Dominique Dumont svn to Git: to split or not to split a repo ?

9. Migration check-list
Identify components of SVN repo
check dependencies between components new repo layout,
best migration order
check impact on tools (CI/CD bug tracker, doc)
identify component with ”earlier adopter” mindset team (may
conflict with best migration order)
migrate
update doc and tools
check impact
repeat for other components
Dominique Dumont svn to Git: to split or not to split a repo ?