Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Svn to git migration: to split or not to split the repo ?

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

  • Login to see the comments

  • Be the first to like this

Svn to git migration: to split or not to split the repo ?

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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 ?

×