[haiku-development] Re: Git/Hg: some speed tests
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 04 May 2011 22:53:18 +0200
On 2011-05-04 at 21:42:03 [+0200], Niels Sascha Reedijk
<niels.reedijk@xxxxxxxxx> wrote:
[ ... ]
> I would like to remind you of the following. The branchy nature of
> hg/git means that revision numbers are not always chronological in
> time. Say on haiku-central there is revision 10...15.
>
> haiku-central: 10 - 11 - 12 - 13 - 14 - (15)
>
> nielx: 10 - 11 - 12 - 13 - 14
>
> Now I made a local commit from revision 14 (which is my [15]), which
> was made before haiku-central revision 15.
>
> nielx: 10 - 11 - 12 - 13 - 14 - [15]
>
> I pull in the the revision 15 from haiku-central, which will then
> become my 16, and I create merge revision 17.
>
> nielx: 10 - 11 - 12 - 13 - 14 - [15] - 17
> \ (16) /
>
> I push my 15, plus 17 back. 15 will become 16 in haiku-central, and 17
> will remain 17. But this also means that revision 16 is older than
> revision 15.
>
> haiku-central: 10 - 11 - 12 - 13 - 14 - (15) - 17
> \ [16] /
>
> So in any case, having persistent tags will not always mean that 16 is
> newer than 15.
Sure, every DVCS has that problem, since there's now more than one
repository. But I don't see your point: on the server, the tags' order will
match their age. In which way does the age matter anyway?
> Now whether git lightweight tags are a solution: imagine if I push my
> changes back to haiku-central. The hook script will create tags. Now I
> will only get those tags if I pull again. It is not impossible, but at
> least it is imperfect.
Hm, just how likely is it that you will never pull again? It's actually
exactly the same process with subversion: looking for a specific revision, I
check my sandbox, if I don't find it there, I update/pull the missing
revision (or just the tag) from the server.
> This brings me back to Ryan's point. What is the use of central
> revision tracking? I can think of only one, which is during build-time
> where Haiku's revision is set. I agree that it might be very
> beneficial to track that, so what we might do is have the build system
> phone home to check whether the current revision is in haiku-central,
> perhaps even add the sequential number (in case of hg). If it is from
> a local commit, or an alternative tree, have it walk up to the nearest
> central revision that it is derived from and note that in the about
> window. During jamming often a network connection is required anyway
> because of fetching the packages, so we are not really adding another
> dependency.
The argument included the notion that incremental revision numbers
facilitate comparing different revisions, e.g. when trying to find out if a
revision mentioned in a Trac ticket is sooner or later than the head in your
local repo.
The part that really baffles me in this discussion is that, when we started
it a long time ago, not supporting incremental revision numbers was
considered a strong argument against git, now that the tide has turned (Git
supporting it and Mercurial not), it isn't important anymore? When I joined
the DVCS "task force", support for incremental revision numbers *was* an
explicit feature request and I invested quite some time to implement that
with git.
We once had the vision that the workflow is more important than the tool
(and you, Niels, were a very strong supporter of that, IIRC). I personally
don't prefer Git over Mercurial, all I'm saying is that Git is a better
match for our intended workflow (as it was outlined before we started the
task force).
Are we instead now going to define our workflow around the tool that will
win the vote?
cheers,
Oliver
Other related posts:
