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

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 5 May 2011 00:42:10 +0200

2011/5/4 Urias McCullough <umccullough@xxxxxxxxx>:
> On Wed, May 4, 2011 at 2:54 PM, Niels Sascha Reedijk
> <niels.reedijk@xxxxxxxxx> wrote:
>>>> Shall we vote on ending the vote? :)
>>>>
>>>
>>> Interesting for the vote would be who is willing to implement it... the
>>> requirements are more or less clear now (IMHO)
>>
>> I think both tools have fanboys (yes, I think I am one of those) that
>> can and are willing to do that.
>
> So, you're suggesting that the vote can continue with the assumption
> that regardless of the winner, a solution to this issue will be found?

Honestly, I don't know what the issue is. I am trying to get my head
around what goes wrong when there is no centralized revision
numbering. Like the example I gave earlier showed, linear revision
numbers are just that: linear revision numbers. In the distributed
world there is no requirement that 40439 came before 43943, it only
means that 43943 was pushed later to haiku-central (the new central
repository) than 40439. Whatever that means.

If the issue we try to solve is 'how do we know that the revision the
user is using is from haiku-central,' then there really is no way to
do that, except by sanctioning our official builds during compile
time. Or by just checking whether the revision SHA someone is using is
in our central repository or not (if it is, Trac will link it, if it
isn't, Trac will not and we can inquire).

Even with the perfectly linear SVN revision numbers it is questionable
what value we derive from it. Yes, we know that 24339 came
chronologically before 25473. But what happened in between requires
investigating the logs and the diffs. The only identifier that is
nearing meaningfulness is the git describe (or the hg equivalent) that
Brecht mentions in this thread, because it describes the name of the
previous tag, the number of changes in between, and the current
revision. This would be useful, except for that it isn't, as we don't
tag releases in our trunk and thus never have a previous tag in our
mainline.

I think what I am trying to suggest is that desire for a centralized
id comes from a fear of the distributed nature. It is the fear for the
moment haiku-central becomes a mere convention, not the mother of all
that is Haiku. The reality is that every clone of the main repository
is a fork in the broad sense: it is a self-sufficient entity. An
independent thing that can be called Haiku, which is only really in
sync when 'hg incoming' and 'hg outgoing' report zero changesets.  But
then again, in sync with what?

The only way to stay in the comfort zone of one central server to rule
them all is to stay with Subversion. Except that you never know when
someone has applied uncommitted changes to the build...

In short: I suggest to let go of the requirement of centrally approved
sequential IDs. Nightly builds by build-o-matic will get a mark in the
version string that it is an official build, as well as builds in
which hg outgoing/git log origin/master..HEAD reports zero changes.
The rest will get a notice in AboutSystem that their build is
non-standard.

Regards,

N>

Other related posts: