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

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 12 May 2011 12:26:26 +0200

On 2011-05-11 at 23:17:57 [+0200], Niels Sascha Reedijk 
<niels.reedijk@xxxxxxxxx> wrote:
> 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:

Thanks!

> 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

I'm still fan of the comparable revision number idea. Maybe the date part 
can be extended by another component to make it unique? E.g. 
"2011-05-11-13" would denote the 13th changeset that day. Would that be 
possible?

> 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...)

Assuming that pushes are atomic, IMO the topmost changeset that had been 
the top after a push would be the best reference point.

> 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.

I'd still prefer if this would also work offline. And yes, I think caching 
is necessary. I certainly don't want to wait several extra seconds for each 
"jam @myimage update kernel".

BTW, how would we deal with references to pre-existing SVN revisions? Our 
Trac tickets are full of those (even some commit message contain 
references). Making them all meaningless when we switch the VCS would 
seriously suck. What means do our VCS candidates provide that would allow 
the mapping? Or maybe we'd rather adjust the tickets to use the new 
revision references?

CU, Ingo

Other related posts: