[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 14:08:25 +0200
Hi,
2011/5/12 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:
>> On 2011-05-11 at 23:17:57 [+0200], Niels Sascha Reedijk
>> I'm still fan of the comparable revision number idea. Maybe the date part
>> can be extended by another component to make it unique? E.g.
>> "2011-05-11-13" would denote the 13th changeset that day. Would that be
>> possible?
>
> In that case I would even leave out the hash code from the central
> repository, as it's then simply not needed (if one can retrieve the revisions
> from the tool this way, that is, but this should be mandatory anyway).
> In any case, I would consider this a viable compromise from the sequential
> SVN revisions, even though I think it certainly sucks to go through all the
> hassle to implement a feature that a DVCS could easily provide on its own, or
> are only not a good idea because of a poor implementation of certain features
> (like the lightweight tags in git, where obviously only their implementation
> is lightweight).
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.
> 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.
>> BTW, how would we deal with references to pre-existing SVN revisions? Our
>> Trac tickets are full of those (even some commit message contain
>> references). Making them all meaningless when we switch the VCS would
>> seriously suck. What means do our VCS candidates provide that would allow
>> the mapping? Or maybe we'd rather adjust the tickets to use the new
>> revision references?
>
> And also in the commit history, and even better, the development list, the
> commit list, and even news items? I don't think that "changing the past" is
> the way to go here. But yes, a solution to this problem should be mandatory
> for a switch.
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.
Regards,
N>
Other related posts:
