Looking up revision number off a central repository

[cowwoc]

  On 03/08/2010 5:00 PM, Matt Mackall wrote:
>
>>       Is there an easy way for non-technical users to find out whether a
>> changeset they are running is before or after another changeset? When
>> developers resolve a bug, QA needs to know whether the current version
>> they are testing is supposed to contain the bug fix or not. Revision
>> numbers make this easy.
> That assumption is incorrect, because history is not constrained to be
> linear. Consider:
>
> 0-1---3-4---6
>     \       /
>      2-----5
>
> Bug fix is in 2, tester is running 3. The only valid deduction about the
> relation between 2 and 3 from their numbers alone is that 2 is -not- a
> descendant of 3.
Hi Matt,

     I'm going to assume the above numbers correspond to changesets (not 
revision numbers) at different points. The tester would only see 
changesets visible off the central repository so in the above example 
they wouldn't ever see "2". They would only see changes made in "2" at 
point "6".

     I believe you understand what I'm asking for: a tester holding "3" 
or "6" needs to be able to ask, "does my current changeset contain point 2?"

> You could do:
>
>    $ hg log -P 3 -r 2
>
> ..which will show 2 if it's not an ancestor of 3, so if there's no
> output, you know 3 'contains' bugfix 2. That'll work with hashes too.
>
> (This is equivalent to -r '2 and not ::3' with hg 1.6's revsets.)
>
> You can make this into an alias like so:
>
> [aliases]
> missing = log -P . -r
>
> Then to figure out if some revision is 'missing' in the current version,
> you run:
>
>    $ hg missing tip   # yes
>    changeset:   11750:26e413f55b5e
>    tag:         tip
>    user:        Brodie Rao<brodie at bitheap.org>
>    date:        Tue Aug 03 13:02:11 2010 -0400
>    summary:     hgcia/color: remove star imports
>
>    $ hg missing 1.4   # no

     You are moving in the right direction but the testers are mostly 
non-technical users. They grab builds off Hudson (a simple website as 
far as they're concerned) and compare version numbers they see there 
against version numbers they see in JIRA. Historically a developer says 
"fixed in r503" and their hudson build reads "Revision 506" so they 
assume their build should contain the fix. If I move them to changesets 
they need an equally simple way of confirming that their build should 
contain a bugfix.

     Ideally I'm looking for a simple GUI or webpage they could use. The 
server "graph" feature is nice but it doesn't indicate the version 
number of each point so it isn't obvious how to compare whether one 
revision is an ancestor of another. Similarly, TortoiseHg requires you 
to jump through hoops to get at this information.

     Increasing revision numbers are inherently simple to work with. I'm 
more than happy to use changesets if I find a way to make them work.

Gili