[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
<niels.reedijk@xxxxxxxxx>:
> 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
unaltered.
> 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:
