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

  • From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 07 May 2011 00:42:37 +0200

On Fri, 06 May 2011 21:37:20 +0200 "Brecht Machiels" <brecht@xxxxxxxxxxx> wrote:
> On Fri, 06 May 2011 17:51:20 +0200, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> >> > 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.
> >>
> >> In 99% of the cases, this is also true for descriptors.
> >
> > You might refer to some other kind of descriptors. The ones Oliver  
> > proposed are not comparable as soon as there are local changes. Which is
> > what I replied to.
> If the user is building an unaltered clone of haiku-central, the numbers
> are directly comparable. If there are local changes, this can be easily be
> flagged and the descriptor of the haiku-central branch the local changes
> are based on can also be provided (ref Niels' post). Additionally, a
> changeset log can be included to give hints as to what might have been
> changed, if necessary.
> The current build system doesn't show that local changes are present, so
> it'll be an improvement at the very least.

That may be true, but why are you writing it? When you reply to something and 
even quote it, the points you make should actually refer to what has been 
written. As I already wrote in my previous mail, I was merely pointing out the 
issue with the descriptors Oliver proposed. Unless you actually address my 
arguments, there's no reason to reply. Other descriptors have been proposed in 
other mails -- there's really no gain in repeating anything about those in this 
dead line of argumentation.

> >> This will be the same for any DVCS. The only reason it's not a problem 
> >> for
> >> SVN, is because you're stuck with a central repository. And that has a 
> >> lot
> >> of other disadvantages.
> >
> > Do you intend to elaborate on what those "lot of other disadvantages"  
> > are? At least so far I was under the impression everyone agreed sticking
> > with a central Haiku repository regardless of what tool we switch to.
> I meant to say that a classic VCS such as SVN has a lot of disadvantages.
> I'm assuming this is why the switch to a DVCS was proposed.

Then I wonder why you wrote it at all. It doesn't help the discussion to 
reiterate stuff that everyone agrees with anyway.

> >> > 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.
> >>
> >> A DVCS offers a lot of advantages for developers. Are you willing to
> >> sacrifice all these just for sequential revision numbers?
> >
> > You seem to suggest that it's either DVCS or sequential revision  
> > numbers. As Oliver originally proposed sequential revision numbers can  
> > be implemented with git via lightweight tags, so the choice is obviously
> > not mutually exclusive.
> What happens in the case of branches? The most recent change in any branch
> gets the next revision number?

That's svn's behavior and it could work just the same with a DVCS. 
Alternatively the sequence could be restarted at the beginning of each branch, 
the revision "number" then consisting of branch name + sequential number.

> Sequential revision numbers simply don't
> make sense in a DVCS, or I'm not seeing something.

Apparently. At least I'm not seeing what problems you see. AFAICT the 
lightweight tag approach Oliver originally proposed would work just like svn 
revision numbers.

> > Alas the lightweight tag solution has performance issues, which is why  
> > we're discussing alternatives since a few mails. May I kindly request  
> > that you follow the discussion before replying?
> You may, but I think we just disagree.

I couldn't even say regarding what point.

> >> With SVN, people can also spread altered builds, and you won't have  
> >> access
> >> to this information. Therefore, I do understand why you make such a
> >> problem out of this.
> >
> > You're wrong. Currently (unless you build from VCS-less bare sources) a 
> > build from a locally modified haiku version *does* contain the number of
> > the respective central revision it is based on.
> Yes, but it doesn't tell you anything about the local changes.

I have real trouble following your argumentation. This whole part of the 
discussion is about the fact that the svn-style revision number built into an 
image identifies the central Haiku revision that the code from which the image 
is built derives from. I assumed that's what you were referring to by "this 
information", and in this case your statement three mails ago is wrong, which I 
pointed out.

Rereading your paragraph, you might instead refer to "people can also spread 
altered builds". In this case: You're wrong. Of course the build system could 
also extract from svn whether there are local modifications and add a character 
or string indicating that to the version number. (BTW, information I'd find of 
very little use.)

Rereading your mail, "this information" might alternatively refer to the 
previous paragraph's "a lot of information can be stored during the build". 

In either case, you replied to (or at least quoted) my paragraph: "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." I'm puzzled.

CU, Ingo

Other related posts: