[haiku-development] Re: 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: Thu, 12 May 2011 17:10:18 +0200


2011/5/12 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> 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?

There not really is such a thing as a mainline. A changeset either is
in a repository, or it isn't. A merge changeset only means that two
heads were combined into one, it does not order those changesets. The
only thing that happens when new changesets are pushed into another
repository  is that that repository gets a new changeset marked as
'tip' (in hg) or HEAD (in git). Note that during a push, all the
changesets that are lying inbetween the existing line in the remote
repository and the merge are pushed, not just the merge.

Say you have this repository (the numbers are changeset identifiers
and do not imply any other ordering):

1 - 2 - 3 - 4 - 5 - 6 - 7 - 10 - 11
                         \ 8 - 9 /

The only thing you know is that if your build is changeset 7, it
contains 1-7. If your build is changeset 8, that you contain 1-6 and
8. And if your build is derived from 11 you have everything which is
in that repository at the moment of querying.

Now you are right in saying that merge changesets perform some sort of
ordering. However, it is not linear/temporal ordering, but
graphical/spatial ordering. They are a fixed point in that they tell
you all that has gone before, but they won't tell you all that has
happened after them (whether or not it has already happened), or that
is happening in parallel.

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

In that sense option 1 would not be completely inviable. The idea here
would be that the script does something like:

wget http://hg.haiku-os.org/haiku/haiku-trunk/rev/46900e539f7b&template=rev

and we would have the haiku-central:39383 identifier. However, my
doubt is that this makes life harder for developers, because they
first have to translate that revision number into a SHA before they
can investigate in their tree, as their tree might have different
revision numbering. So perhaps the idea of a revision number is better
to let go.



Other related posts: