Re: Mass svn-to-git migration - Progress report
On Wed, Apr 12, 2023 at 07:35:30PM +0200, Diederik de Haas wrote:
> On Wednesday, 12 April 2023 18:45:31 CEST Jelmer Vernooij wrote:
> > I think the git repositories should just be created directly under
> > debian/. There's no reason not to, it makes it easier to find them
> > (not everybody will know about the alioth-to-salsa-migration-team),
> > and removes the need to create a separate group and to fork them to
> > debian/ later. There's not much controversial there - it's just pure
> > git to git.
>
> If debian/control points to the alioth-to-salsa-migration-team repo, it
> shouldn't be hard to find.
It seems simpler to just immediately push to debian/ where we would
eventually expect the majority of repositories to end up anyway. It
may be simple to fork, it's simpler to not even have to fork.
(I don't think that holds for the SVN imports, where people probably
want to do a lot of post-processing)
If you're planning to update debian/control in a way that's visible to
people you'll have to do NMUs. It seems bad form to do NMUs updating
the Vcs-Git field to point to a repository that the original
maintainer doesn't have access to.
> > On the subversion migrations, the hardest part is in dealing
> > with the differences in habits between svn-buildpackage and git-buildpackage
> > (or whatever you're expecting people to use). You'll need
> > to convert svn-buildpackage settings to e.g. git-buildpackage somehow, and
> > e.g. potentially weave in the upstream sources
> > (lots of packages in svn ship just debian/ whereas in git it's common
> > to include the upstream source). If you don't do that, then
> > it's probably better to not do a conversion from svn at all, but e.g.
> > do a straight import from the archive (e.g. based on the dgit
> > repository).
>
> Then it's better to abort the migration attempt at all and do a straight
> import from the archive.
>
> I wanted to convert id3lib to git and then use that to *learn* packaging with
> git-buildpackage (and related stuff). But if I first have to learn that and also
> svn-buildpackage, which I really don't want, then it's kind of pointless for
> me. It would also increase the amount of work 10 or 100 fold?
> And I have no idea how I would _assume_ how other people would use it as I
> know virtually nothing about (git) packaging myself.
>
> The idea I had with the a-t-s-m-t repos is that I would not (have to) assume
> anything about how a prospective maintainer would want to do their packaging,
> but leave that choice entirely up to them. That's why I wanted to leave open
> the option of them being able to rewrite the git history to suit their needs
> and before the repo would be moved to f.e. the debian/ namespace.
> All they would get is the old SVN repo, but converted to git.
FWIW I think there's value in making conversions of the SVN
repositories available as Git repositories, if they're not usable
as-is; it at least removes some of the steps in migrating packaging
from SVN to Git, and provides a start for migrations. But there's more
post-processing / conversion necessary beyond that for packages to
function like other Debian packages in Git.
Cheers,
Jelmer
Reply to: