[haiku-development] Re: VOTE: Git or Mercurial (hg) as Haiku's new source control tool

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 13 May 2011 23:59:26 +0200

On 2011-05-10 at 23:49:36 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> 
> Hi,
> On 2011-05-10 at 22:58:30 [+0200], Niels Sascha Reedijk
> <niels.reedijk@xxxxxxxxx> wrote:
> > 
> > 2011/5/10 Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>:
> [ ... ]
> > >
> > > Okay, I will play around with the 'hg' get revision number during
> > > build. Maybe someone else can try for git.
> Sure, I was planning to do that, maybe tomorrow, maybe Thursday.

Ok, I finally found the time to implement a way of fetching somewhat useful 
revisions from git repos. 
They look like this (for a clean state, i.e. a revision from Haiku's repo):
or like this (for a revision not available in Haiku's repo):
        haiku/master-39387-g7654321 [haiku/master-39382-g1234567]
or even like this (for a revision with changes in the working dir):
        haiku/master-39387-g7654321-dirty [haiku/master-39382-g1234567]

Those revisions aren't pretty, but they:
* always refer to the central Haiku revision they're based on
* contain the central branch they're based on
* contain the local branch they're based on, helpful for identifying 
  different revisions of public clone repos (e.g. on github) or your local
  topic branches
* are more or less comparable, i.e. a revision with a higher distance 
  (second column) usually indicates that it is newer than another revision
  with a smaller distance. This is not true for revisions living in 
  separate anonymous (now merged) branches, but with a DAG instead of 
  history, there's simply no numbering that can accomplish this, so even 
  lightweight tags would be no help.

The revision is cached (i.e. only updated when the hash of the working dir 
changes) and determining it does not require a network connection, since 
the implementation uses one lightweight tag per branch in order to track 
the last central revision the current tree is based on.

If that still isn't good enough, I think all we can do is to stick with 
subversion as central repository.
Using {git,hg}-svn against the central subversion is possible (I have only 
tested with git-svn), but it can't really be recommended for general use, 
as it takes slightly more than 4 hours to do a clone with git-svn (instead 
of 5 minutes with git). One way around that would be to host a "official" 
git-svn repo on github/gitorious and regularly sync (dcommit) that with the 
subversion repository (although this can fail and would require manual 
intervention at times). Using a public git-svn repo would mitigate the 
performance problems of git-svn, but it would lose the advantages of 
git-svn for each developer, too, i.e. the rXXXXX revision numbers can not 
be used in git directly (they can be used with git-svn). OTOH, one can 
always find out the hash corresponding to a specific SVN revision with 'git 
log --oneline --grep="trunk@XXXXX "'.


Other related posts: