Re: Moving GLib and GTK+ to git

[Kristian Høgsberg <krh redhat com>]

On Mon, 2009-03-30 at 12:47 -0400, Matthias Clasen wrote: 
> Last week, I said that I'd like to get this done by the end of March,
> which is almost upon us now.
> 
> Therefore, I'd like to ask everybody to hold off with committing to
> svn. While we are not quite ready to start the migration yet, it will
> begin sometime later today. So to avoid duplicate work, it would be
> best to wait with further commits to glib and gtk+ until the migration
> is completed. I'll send another email with checkout information, etc,
> when the conversion is done.

The glib and gtk+ repositories are up now and they are live:

  http://git.gnome.org/cgit/glib
  http://git.gnome.org/cgit/gtk+

and I've been verifying that master and all tags are identical between
git and svn.  There are some differences for some of the older cvs tags,
but it looks like they break down into two cases:

        1) CVS tagging races with a commit: person A does cvs up, cvs
        commit, make dist, person B does cvs commit, A does cvs commit,
        and gets no conflicts with person B's commit, then does cvs tag.
        The tag now references files from before the B commit and file
        from after the B commit.  This is possible with CVS and SVN can
        represent it by breaking the svn cp for the tag into a
        piece-wise copy from different revisions.  With git, a tag just
        points to a existing commit, so to do this, we'd have to create
        a commit that matches what the cvs tag contains.  Check out
        1.3.12 for an example.  It's only a problem for a few old cvs
        era commits and the effect is that the git tag will contain a
        commit that wasn't in the tarball or cvs tag.  It won't affect
        other parts of history, specifically, git blame information is
        still accurate.  I've talked with Owen and Matthias about it and
        we don't feel it's an issue that's worth tackling.
        
        2) CVS repos that were copied into the gtk+ repo on the server.
        Three main cases are gdk-pixbuf, the reference docs and the
        pixbuf theme engine.  These were all either started as their own
        cvs repo or part of another repo.  The RCS (the ,v files) were
        copied on the server to pull them into gtk+ with full history.
        CVS implements tagging by tagging every RCS file, so every RCS
        contains all the tags from the repo, and when you move an RCS
        file, the tags move with it.  Git doesn't support tagging just a
        sub-directory so what the CVS to git importer does in this case
        is to expand the tag to cover the entire tree.  This means that
        a gdk-pixbuf tag from when it was an independent repo will now
        include gtk+ files in it and vice versa.  The consequence is
        that checking out an old gtk+ tag from before gdk-pixbuf (or the
        docs or the pixbuf theme engine) got merged may have the
        gdk-pixbuf files in it.  Again, this only affects older CVS
        tags, doesn't throw away information and most important, doesn't
        affect git blame output.  Ideally we could split out the
        gdk-pixbuf history from before the RCS files got copied into a
        branch with a different initial commit and create a merge commit
        where the two histories join.  I'm going to take a couple of
        hours to look at this, but I suspect it may not doable with
        reasonable effort.  I mean, this theory is nice and all, but
        when it comes down to the nitty-gritty shell-quoting details of
        making it actually work I may end up concluding that it's just
        not practical.
        
So, with the caveat that we might rebase the gtk+ repo, glib and gtk+
are now in git!  If we end up getting a fix for 2), we'll rebase and
replay whatever commits happened in the meantime to the rebased tree.
If you don't know what to do if an upstream repo rebases, it's probably
best to hold off committing to the git repos a little longer.  Other
than that I'd say we're ready to go, but I'll leave it to Matthias to
make the call.

cheers,
Kristian