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

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


2011/5/5 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>> 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.

Here's what I found out. I suggested earlier to have the build script
check what the relation of the current source tree with haiku-central
is, at the same stage where now the svn revision number is fetched.

With some help on #mercurial I found that the following would get
close to what we want:
hg log -r "parents(roots(outgoing('http://hg.haiku-os.org/haiku/haiku-trunk')))"

It outputs the log message of the furthest parent revision on
haiku-central (given the right argument to outgoing). [That's not
perfect yet, but it is close]

Now I don't know how this would work in git (the guys in #git did not
reply), but I imagine it works something like this:
1. set up a remote to haiku-central
2. fetch
3. compare the differences between the current branch and haiku-central
4. find out the parents of those changes

Thus the build script can generate a string that is useful in that it
can refer to changesets in haiku-central.



Other related posts: