[haiku-development] Re: Git/Hg: some speed tests

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 4 May 2011 21:42:03 +0200


2011/5/4 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>:
> Hi guys,
> On 2011-05-04 at 16:48:29 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> wrote:
>> Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx> wrote:
>> > === Checkout on Haiku ===
>> Thanks for all the tests! Judging from the syntax alone I would prefer
>> hg :-)
>> Does all those commands work on Haiku as well?
>> I don't find the complete checkout times that important, how does
>> rebasing the local repository to a more recent revision look like?
>> How fast is switching between branches?
>> How fast is creating a new branch?
>> How fast is merging a branch?
> While interesting, all of these speed tests are pretty moot (as is the
> vote!), unless someone can help me solve the following problem:
> We intend to use incremental global revision IDs in order to be able to
> identify revisions across different repositories, right?
> Mercurial does have support for revision-IDs, but these are not at all kept
> identical across different repositories. Whenever you pull from the
> upstream repo, the revision-IDs will change when you have committed local
> changes to your repo. So how does one find the local revision corresponding
> to a specific revision ID in the central repo? I have thought about this
> for a while but have not yet been able to come up with a good solution.

I think the only 'real' solution is to discard the use of revision
numbers in our daily communication, and move to SHA1 tags.

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.

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.

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



Other related posts: