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

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 11 May 2011 23:17:57 +0200

Hi,

2011/5/10 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> On Tue, 10 May 2011 21:15:48 +0200 Niels Sascha Reedijk 
> <niels.reedijk@xxxxxxxxx> wrote:
>> I don't remember exactly how long our standard voting time would be (7
>> days?). Anyway, I miss many names in this threads, so let's suggest we
>> run this vote until Saturday 00.00 GMT?
>
> I don't know about the others, but my vote is still pending, because I don't 
> feel I can make an informed decision yet. E.g. the whole revision numbers 
> topic has been discussed at some length, but the proposed solutions are not 
> optimal and mostly theoretical. I assumed Oliver's recent changes were done 
> to be able to actually test some of those theories, which I find an excellent 
> idea.

Well, here's my attempt at getting a meaningful revision string (like
I put in the other thread). For my tree, with two custom commits, the
output would be:

custom:64fc2d4b5805~2011-05-11 derived from
haiku-central:47b487e35b93~2011-05-07

In case of connection troubles, it would be:

unverified:64fc2d4b5805~2011-05-11

A 'pure' build would be:

haiku-central:b62bc712a76b~2011-05-11

The script takes into account when a custom build is derived from more
than one haiku-central revision. This could be the case when a custom
development branch has had several trunk or branch merges. I am not
sure yet whether this is necessary or the most optimal, (now that I
think of it, only the topmost changeset would be interesting...)

The downside of this version is that there is no caching. In the worst
case, two or three calls (depending on whether hg does some caching)
to haiku-central are made. Also, it does not adhere to the 80 column
standard and I never did anything bash before.

Regards,

N>

Other related posts: