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

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 05 May 2011 01:32:42 +0200

On Thu, 5 May 2011 00:42:10 +0200 Niels Sascha Reedijk 
<niels.reedijk@xxxxxxxxx> wrote:
> 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.

It means that running a 43943 (derived) version contains all the changes up to 
that number. No, there's nothing wrong with not having a linear revision 
number, but it makes things significantly less convenient. When I read "bug 
fixed in 40439" and I run 43943 then I known my version includes the bug fix, 
while it doesn't the other way around (unless I pulled the fix from some other 
repository before it went to haiku-central). When I read "bug fixed in 
8d5dc105106fb0bf1fe83494a184ca740278745f" and my Haiku is 
037ea432d72fa9246f0e6b59aba861055d2345bd, then that tells me exactly nothing 
without looking it up. Even the "describe" stuff is only marginally helpful: 
Does "r1a2-192-b969c5a" include bug fix "r1a2-190-892f219"? If the latter is 
from the haiku-central and the former doesn't have any local changes then yes, 
otherwise maybe or maybe not.

> 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).

Whether the exact haiku-central is run or not is usually not relevant. If I 
report a KDL, it doesn't matter that I have local MediaPlayer changes. It is 
sufficient to know (and already logged to the syslog) what the closest 
haiku-central revision is.

> 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.

Just from the number I already know that 1134 change sets happened in between 
and that this is more than 15000 change sets removed from the current head 
(i.e. the reporter should try a newer version).

> 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.

Indeed. Tagging daily would already improve the situation. Tagging each 
changeset would be perfect. Oh, wait, that's revision numbers!

> 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.

*me starts aching for a drink*

[...]

CU, Ingo

Other related posts: