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

On Thu, May 5, 2011 at 7:42 AM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
>
> On 2011-05-05 at 01:58:12 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
>> On Thu, 05 May 2011 01:44:43 +0200 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
>> wrote:
>> > We could tag the very first changeset of every branch (i.e. in master and
>> > every release branch) and then use 'git describe' to work out a revision
>> > descriptor that would look like this:
>> >
>> >     master-39148-g206031c              [in the master branch]
>> >     r1a3pre-21-g1234567               [in the r1a3 release branch, before
>> >                                     the release]
>> >     r1a3-4-g1234567                   [in the r1a3 release branch, after
>> >                                     the release]
>> >
>> > The numbers in the second column always indicate the distance the specific
>> > revision has from the tag given in the first column (the third column
>> > being
>> > git's short hash for the changeset).
>> >
>> > This would require only one tag for each branch plus one per release.
>> >
>> > Additionally, incorporating these descriptors in AboutSystem would clearly
>> > indicate "foreign" builds (e.g. done from a feature branch available on
>> > github/gitorious), as those descriptors wouldn't match any in the central
>> > master.
>>
>> 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? 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.
>
> 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).

To this end, there is a mercurial extension called 'contains' which
automates this check.
The syntax looks pretty simple:

hg contains <changeset id>

will tell you if your local repo has that changeset in it. This could
also be very handy for bug reports, eg. fixed in x, please report `hg
contains x`. The extension also has some other features, anyone
interested can check it out here:
http://mercurial.selenic.com/wiki/ContainsExtension

Git has an equivalent feature, git branch --contains, which works
basically the same way.

> 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.
>
> cheers,
>        Oliver
>
>

Other related posts: