Git Migration: github with svn access

[Geert Janssens]

Op woensdag 28 december 2011 17:08:13 schreef John Ralls:
> > Heh, don't underestimate the configuration of our Windows build server.
> > 
> > It checks every night if it has to (re)build some tagged versions. It
> > does this by making a list of all tags (and their associated revision)
> > and comparing this with yesterday's list. If there is any tag/revision
> > combination that doesn't exist yet, it will rebuild this tag.
> > 
> > So if the revision numbers in git don't match those in our own svn tree,
> > that means that the server will attempt to rebuild every tag that is
> > present in the tags directory (well to be precise each tag of the
> > format x.y.z). That will cause a lot of (useless) rebuilds for one
> > night.So before we switch the tag builds to use git, we better
> > 1. be very sure the git created revision numbers never change
> > 2. manually recreate the tag history file based on git's revision
> > information.
> > 
> > But other than that I don't consider this a big issue. Assuming the svn
> > access github provides will be stable, and is meant to replace our own
> > internally managed svn tree, the numbering mismatch is only a temporary
> > inconvenience.
> ISTM it would be better to have the release script look at the SHA reference
> in the tag using git rather than to depend upon Github's subversion
> gateway.
I'm not opposed to this idea as such, but the whole discussion so far was 
focussed on the idea of reusing the svn based automated build scripts, to 
avoid the need to change everything in one go.
I've been giving my feedback with that idea in mind.

Last time I checked (a few minutes ago), git support on Windows was still in 
beta, at least the project I found:
http://code.google.com/p/msysgit/

Perhaps there's another one ?

> We probably want a bit more sophistication in the check than just
> a tag; with git people make tags (and delete)  tags for all sorts of things
> besides releases... so maybe a keyword ("RELEASE"?) in the log summary, or
> a particular format for the tag ("GnuCash-Release-2.5.1"?). That would also
> save us the trouble of backfilling the history file (not that that's hard)
> since none of the existing tags are likely to meet the new criteria.
> 
Agreed here.

Geert