[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 15:21:13 +0200

On Thu, 12 May 2011 14:08:25 +0200 Niels Sascha Reedijk 
> 2011/5/12 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> Replying mostly to Ingo here: replacing the hash with a number would
> not work the way you'd expect, because it is always possible to push
> changesets that were committed on a certain date.
> So say that on the 13th of April there were two changesets:
>  * one at 08:00
>  * one at 16:00
> My build is based on #2: so I would be 2011-04-13-2. Now after I build
> you push your changesets that you were working on in a sub-branch. One
> is on April 13th at 12:30. This would mean that if someone would look
> at my bug report, they would identify it based on your changeset at
> 12:30, not on the one at 16:00.

I thought merging that 12:30 changeset would necessarily result in a merge 
changeset and the 12:30 changeset would never be in the main line (or however 
one would call it) of the master branch. Is there a way to access only this 
main line of a branch instead of all changesets that (possibly indirectly) 
contributed to it?

> > BTW why are the repository-centric revision numbers that at least hg
> allows for not adequate again?
> They are very adequate when labeled correctly, but the issue is in
> identifying them in a local repository. There currently is no way to
> retrieve revision numbers of a foreign repository with the standard
> mercurial. There are two options:
> 1. Write a simple app that runs on our servers (hgweb extension maybe)
> and takes request for changeset hashes, and returns the haiku-central
> revision number. Would fit in this script perfectly, but does require
> a network connection.
> 2. Write a hg extension that keeps a local revision map of
> haiku-central. This map can be queried during build. Upside: no need
> to be connected, downside: you need a manual intervention to install
> this extension.

I would rather avoid any kind of non-standard extensions. Ideally the VCS tool 
would just be installed via the standard means of the OS/distribution and work 

> Speaking for hg: the current converted repository contains the svn
> revision number in the commit message. It can thus be queried with a
> hg log filter. I am sure that on dev.haiku-os.org we can do a similar
> 'soft' conversion where the proper changesets are linked to the
> revision number. Git also tags the svn revision numbers in the
> changeset message, so there similar techniques could apply.

Would adding a revision number to the commit message when changesets are pushed 
to the server be possible? Or does that change the identity of the changeset 
and/or lead to clashes?

CU, Ingo

Other related posts: