On Friday, 27 January 2023 20:14:43 CET Jelmer Vernooij wrote: > Hi Diederik!
Hi Jelmer! > I agree, I think anything that reduces the complexity of the ecosystem > is great and the lowers the barrier for entry. As pretty anything uses > Git now, I think migrating more things from SVN to Git would be great. Great and I agree :-) > On Fri, Jan 27, 2023 at 07:56:37PM +0100, Diederik de Haas wrote: > > I wouldn't be surprised if most people would bail out at the first 404 > > message. > > > > There must be a better way? > > - I don't know if someone has already done this migration and could share > > their experience/tools/etc? > > - If it needs to be done, isn't it way better to do a mass-migration of > > all the repos which haven't been converted yet? There may be a high > > similarity between the various SVN repos, but all the projects within one > > SVN repo likely share many things? Like svn-user to git-user mapping? > > - And then update d/control so that the PTS page links directly to the > > salsa repo? > > (- I don't know if snapshot.d.o could/should play a role in this) > > > > Would love to hear some thoughts on this. > > I've been looking at how to do a mass conversion. There's about 375 packages > still listed as being on alioth (~100 in SVN, ~267 in Git, the rest in > something else). > https://janitor.debian.net/cupboard/result-codes/hosted-on-alioth?campaign=u > nchanged&include_transient=off&include_historical=off I'm so happy with these things and the janitor work in general :-) I have a lot to learn and most of what I do is manual labor. Doable when the volume is low, but for mass-* that would get problematic. > Here's what I have so far: > > * A scheduler script that determines what things still claim to > be hosted on alioth and finds the matching archive > > https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/sche > dule/vcswatch-candidates.py (based on vcswatch data in UDD) > > * A "import-from-alioth.py" script > (https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/imp > ort-alioth-archive.py) that takes an alioth archive and pulls it into the > local repository. > > * lintian-brush has a mapping of team names to locations in salsa, > here: > https://salsa.debian.org/jelmer/lintian-brush/-/blob/master/lintian_brush/s > alsa.py I have recently (re-)started my attempts to learn Python, which is something I actually want to learn ;-) I'll look at/study them, but I probably won't be able to help much (soon). But I won't mind helping out in other ways with f.e. manual labor. > What still needs to happen is: > > * The mapping still needs to be tied together with the import script, to > generate correct URLs to push to and set the Vcs-* headers > appropriately > > I'm not sure what to do with packages whether the owning user or team > is not on salsa. Add them to the "debian" group? I think it would be easier (and possibly better) to create a separate subgroup under the debian group. Moving the converted repo is probably sth that should be done manually. F.e. the id3lib repo does exist on salsa, but is useless. Detecting the exact state of a repo (directly) under 'debian' may not be possible and/or be WAY too involved. And you probably also don't want to run the risk of accidentally overwriting an existing repo. As I *think* the majority of the work is actually converting repos and getting them in salsa at all, doing that in a new 'namespace' seems easiest. And safest. And then you can still automatically set the Vcs-* headers. If at a later point the choice is made to move a repo to a better place, then updating the Vcs-* headers should be rather trivial. > * The import script supports just git right now, not svn. There's ~8 > repositories in a VCS other than SVN or Git, which we could just > migrate manually. Agreed. > * Verification that this is all working well > > * and then perhaps gradually rolling it out, starting with QA packages. > then perhaps getting buyin from the maintainers of the packages > involved and doing the rest. I do have the 'collab-maint' archive locally, both in .xz format as extracted, so I could run test conversions 'endlessly'. I believe that's the biggest one, but I could also retrieve a smaller one for initial testing and when that works properly, do it on 'the big one'. Cheers, Diederik
signature.asc
Description: This is a digitally signed message part.
