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 _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
