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

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

On Thu, 05 May 2011 15:42:02 +0200 Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2011-05-05 at 01:58:12 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> > Maybe I misunderstand something, but when I clone the haiku-central
> master 
> > master-39148-g206031c and make three local commits I get something like 
> > master-39151-g0329483, right? So that doesn't really tell us which 
> > haiku-central version my version is based on -- it could just as well be
> 5 
> > local commits after master-39146-... or 10000 local commits after 
> > master-29151-....
> 
> Hm, 10000 local commits in master - you're kidding, right?

I was just making a point: The number isn't telling much.

> 5 is more like
> it, 
> and those should be dealt with before starting a new task (which is most 
> probably what's hiding behind the need to interpret revision numbers). 
> I could live with revision IDs only being 100% reliable on a clean master.

Of course I can somehow extract the information from the repository. If it were 
only about that the hashes would suffice just the same. The advantage of 
revision numbers is that the numbers themselves are comparable.

> Anyway, I think the problem you're describing is a non-issue: Whenever you
> encounter a revision descriptor (e.g. in Trac) and you can't find it in
> your 
> (up-to-date) local master, that revision is not from the central repo
> (there 
> may be one with the same distance, but the short-hash won't match). 

We appear to disagree on the categorization. The mechanism only working for 
unmodified clones of a haiku-central branch is a limitation which I do consider 
an issue.

> Additionally, it doesn't really matter which upstream the hacked revision
> is 
> based on, since you can never be sure that the local changes are not the 
> cause for the problem. So, I'd strongly advise people (and we could add a 
> check) to only ever use revision descriptors from the central repo in
> Trac.

As a developer I often run a modified Haiku version. And when working on 
something I can usually judge whether my changes can cause a certain bug. 
Having to hunt down the revision descriptor of the haiku-central version my 
modified version is based on (instead of just copying it from AboutSystem or 
the syslog) is a nuisance.

Let's keep in mind for whom we're going to switch the VCS: For the developers, 
not the people who just want to build their own images.

CU, Ingo

Other related posts: