Further updates: I used my sprint time at PyCon.ZA to poke at the migration. I was lucky enough to have Gary van der Merwe, with deep VCS experience, get involved, and we made some significant progress.
http://anonscm.debian.org/cgit/users/stefanor/dpmt-migration.git/ svn2git.py Takes the SVN repository, and spits out a billion git ones. If you want to run it, you can find dumps of the svn repo in my home dir on alioth. I recommend loading the dump in /dev/shm (and putting the git repos there, too). Gary figured out how to de-octopus all the svn-buildpackage tags, to create a linearish history. (svn-buildpackage tags by copying your working directory to the remote, meaning different directories can be at different revisions, and the tag has multiple ancestors) We determined that my unhappyness with git-dpm history (the debian directory appearing from scratch on after every upstream merge, rather than having a useful history) is the result of a bug in git-dpm's import code, it's missing a parent link between these commits. But we didn't find where the bug is (or write a detailed bug report). Right now, we're not trying to convert to dpm, but just to svn-buildpackage style (which is simpler). https://bugs.debian.org/720448 means that history isn't round-trippable through dpm, without adding noise. This probably wouldn't go down well with the release team when preparing stable package updates for before the migration. The next step (which Gary is working on) is to start combining the imported-from-svn tree with an imported-from-dscs tree, so that we have full source packages, with all the svn history. I'm busy paying down all the technical debt we took on in the svn2git rules, to get the conversion running in a hurry. We need to capture all the branches, to have less disconnected tags in the repos. > I took a look at Stefano's dpmt-migration branch. His code is working at a > different level than mine; whereas I am working on single package imports, > he's looking at doing the full migration of all DPMT and PAPT packages. We'll > need that whenever we flip the switch. This might have been a bad approach (on my side). To perfectly migrate all repos, we may have to do multiple runs (with individual rules files) rather than one all-in-one migration. The reason for that is that svn2git only writes each svn change to 1 git-repo. It can't understand that repos will fork from each other later, and changes must be written to both, until then. (e.g. beautifulsoup gets copied to beautifulsoup4, but both are still in the archive) We could also deal with that situation by running svn2git for n revisions, copying git repos, then running another m revisions, etc. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
signature.asc
Description: Digital signature
