[Debichem-devel] Git migration plan
stuart at debian.org
Thu Jan 25 03:40:59 UTC 2018
Many thanks for the considerable amount of work that has gone into that rules
file and testing it out.
> Now many of our packages have a clean subversion history and the
> resulting GIT repositories look fine to me. Others had a more
> complicated life, especially when branched off or tagged several times.
> For these I did my best to make sensible decision writing the ruleset.
> I checked the results by looking at the graphical log version (git log
> --all --graph) and the references (git show-ref). I also imported the
> results several times to salsa.d.o.
A common problem I've seen in the conversion is that the tagged commit made by
svn-bp is actually a separate commit that is off the history rather than
simply a tag on the final commit. This is only seen in some situations but
I've not worked out which combination of svn, svn-bp or workflow leads to it.
Programmatically fixing it is not impossible but is difficult.
Personally, I've not worried about such things since the tag has the correct
content, it just doesn't appear within the linearised history.
> - Packages ignored are those
> Their files go into a fake repository called "junk" (based on Stuart
> Prescotts ruleset).
FAOD, it was never my intention to do anything with junk.git; it only existed
in my rules to stop svn-all-fast-export from dying on the import and would be
never be uploaded to salsa. I don't think it is of any interest to keep, but
have I missed something there?
> So if you would like to help, these are the tasks and open questions
> left before the conversion:
> - Is it ok to use a branch wnpp or shall it be named differently?
For old packages, sure, let history be history. Or squash that branch into
master. I don't think it matters in history.
For future packages, I don't think there's a need for a different branch name
for not-yet-uploaded packages. (It made sense for the svn workflow where
everything was in one repository but less so with separate git repo per
package. I guess we would be reliant upon blends or PET or similar to keep
track of never-uploaded packages.)
> - Are there hooks, templates, ... etc. that should be created for every
> repository? Do we need to setup a repository template at
> salsa.debian.org for every repository? Is there anybody already
> familiar with the latter?
There are two options here -- straight to salsa or park on alioth for a short
period. I suspect going straight to salsa is a better idea.
Hooks can be enabled on salsa using its http API (as can creation of the repo
itself within a team). I think the current state of the art is described at
although all of this is sufficiently new and volatile that we may have already
moved on from there.
> - Tags called backup/* are used by svn-all-fast-export to mark the last
> commit, before a branch (sometimes tags, but these should all be fixed
> already) was deleted. These can be removed if you feel no need to keep
> them. Please check the graphical log and/or the subversion history if
I notice in your script that you are copying the bare repo created via svn-
all-fast-export. Instead, it is best to immediately clone that repo (either a
bare clone or otherwise). There tends to be a lot of mess left in the repo
that svn-all-fast-export creates (including all these backup tags) and from
memory that initial clone lets git get rid of them. The call to git-repack
does some of this but the recommendation is to clone. (Yes, I am painfully
aware that svn-all-fast-export is woefully underdocumented; unfortunately,
it's a tool that by the time you've become expert enough in using it, you
probably stop using it because you've done all the conversions you need.)
I agree that these tags should be removed prior to pushing to salsa.
Final steps in the conversion that can be considered:
- make an index for mr (aka myrepos) to automate fetching all repos within the
team. (Not my cup of tea but those used to doing mass changes to all packages
via the omnibus svn repo tend to like it.)
- updating debian/control to add Vcs-Git, remove Vcs-Svn and update Vcs-
Browser; a simple sed is probably enough but I can help with python-debian's
deb822 if not. I assume it's worth doing that on all packages immediately even
if they are not yet uploaded.
BTW I started looking at git-buildpackage to see if those hooks could be
extended to have further substitutions for you. It looks possible but I've not
had time to do it and test it.
Stuart Prescott http://www.nanonanonano.net/ stuart at nanonanonano.net
Debian Developer http://www.debian.org/ stuart at debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
More information about the Debichem-devel