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

  • From: "Brecht Machiels" <brecht@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 06 May 2011 21:37:20 +0200

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.

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.

> 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? Sequential revision numbers simply don't
make sense in a DVCS, or I'm not seeing something.

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.

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.

Cheers,
- Brecht

Other related posts: