[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 18:17:09 +0200

On Thu, 12 May 2011 17:10:18 +0200 Niels Sascha Reedijk 
> 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.

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

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.

CU, Ingo

Other related posts: