[haiku-development] Re: Git/Hg: some speed tests
- From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 4 May 2011 23:30:06 +0200
Hi,
2011/5/4 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>:
>
> On 2011-05-04 at 21:42:03 [+0200], Niels Sascha Reedijk
> <niels.reedijk@xxxxxxxxx> wrote:
>> 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.
You're right.
>> 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.
What I am still trying to wrap around is in which cases we need the
centralized revision numbers to be available decentrally. I understand
Axel's argument that you might need it when checking a bug report. But
I don't see what the issue is to simply run a command
hg log --rev 8923682835cd:
to check what came after the reported rev 8923682835cd...
> 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?
No, that sounds bad. But if you found a solution for git that is
essentially a hack (sorry, customization), then that doesn't mean that
there won't be a similar type of solution with Mercurial.
Here's one (that admittedly requires some checking for
implementability). It should be possible to come up with an extension
that during a pull creates a map of all central revision numbers. it
should then be possible to specify them in the commands as if they
were tags. As an added bonus, this extension might also map the svn
revision numbers. So you can do a:
hg checkout r49430 (svn revision)
hg checkout haiku:43449 (haiku-central revision)
The extension can be available by default on Haiku, and easily
installed by those who want/need it on any other platform. Advantage:
no clouding up of tagging namespace.
N>
Other related posts:
