[Debichem-devel] Git migration plan

[Stuart Prescott]

Dear Daniel,

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

http://blog.dogguy.org/2018/01/salsa-webhooks-and-integrated-services.html

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
> necessary.

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.


regards
Stuart


-- 
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