[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 18:59:43 +0200

Hi,

2011/5/12 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> On Thu, 12 May 2011 17:10:18 +0200 Niels Sascha Reedijk 
> <niels.reedijk@xxxxxxxxx>:
>> 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.
>
> As a theoretical computer scientist, I would argue that, since I can define 
> it, it does exist. :-) I define it as the chronological sequence of all 
> tips/heads. Hence my question whether the tools allow to access/reconstruct 
> that information. I assume you're saying that both tools (?) only store the 
> current state of the changeset DAG, or IOW when I push new changesets the 
> information what the old tip was gets lost.
>
> That's a bit unfortunate, but does not present a insurmountable obstacle. The 
> server could maintain a repository object storing the necessary information 
> to reconstruct the main line. That object would 1. need to be propagated 
> automatically when pulling from the repository and 2. it must not interfere 
> with branches/changesets in any way.
>
> Git's annotated tags might have those properties. Don't know about hg.

I think you are onto something. When Mozilla switched to hg, they
created their own 'pushlog' system, which in one sense is a sort of
threaded view of commits, based on the points in time that they were
pushed to mozilla-central.

See http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=7ce9c33853c6

Now it is possible to reconstruct a temporally linear line of
tips/HEADs using this system (based on push-time, not commit-time).
Now I have to note that Mozilla seems to use it mainly for
acccountability (who pushed that changeset from the unknown person
here), but that does not mean we can't extend its uses.

Just for fun we can continue numbering the changeset identifiers from
our current svn revision!

>> >> > 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.
>
> Hashes and revision numbers aren't mutually exclusive. I don't see a reason 
> not to build both into the Haiku images. In Trac I would expect that giving 
> either would result in a link to the correct changeset. So, I I guess in most 
> cases when the hash would be needed, it is already available anyway. In the 
> other cases the revision number would indeed have to be translated. A 
> script/alias/extension/whatever could be provided to help with that.

Sure. I think that those who are interested in that (core developers)
do not mind to tweak their working environment anyway.

> A way to directly use the revision numbers in the tool would, of course, be 
> great (git's lightweight tags sounded so good *sniff*). Since anything seems 
> to be possible with hg extensions, maybe an extension to allow using those 
> revision numbers directly would be, too. Again, that should be optional, 
> though.

I am pretty sure this is possible. A possible clue to implementing
that would be by looking how the bookmarks extension does it. Anyway,
referring to revisions by means of haiku-central:44334 would not be
impossible.

Generating a haiku-central revision number offline would remain
difficult if not impossible (without custom extensions anyway).

Regards,

N>

Other related posts: