non-chronological rearranged revision numbers: bug in churn, or base mercurial?

[Haszlakiewicz, Eric]

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Kastner Masilko, Friedrich
> 
> > From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Haszlakiewicz, Eric
> >
> > R1--->R2----------------R5(TagA)--->-R6(merge)--->R7(TagB)
> >        \----->R3-->R4---------------/
> >
> > I'm trying to use the churn extension to show a count of lines that
> > changed between TagA and TagB:
> >
> > hg --config extensions.churn= churn -r TagA:TagB
> >
> > But it's only showing a count of the changes made in R7.
> >
> > hg diff -rTagA:TagB
> 
> From what I understand, Mercurial's x:y notation returns the
> numerological range and not the topological one, meaning that a range
> of R3:R6 in the above example would return R5, too. If you want the set
> (R3, R4, R6), you could use the revset notation R3::R6.
> 
> That said, it isn't actually your problem here as I see it, I just
> wanted to note this behaviour.

That doesn't do what I need either.  I'm trying to get churn to give me all changes between two "releases" that I've done (hence the tags), but both "TagA:TagB" and "TagA::TagB" give me R5, R6 and R7.

Thanks for the reminder about revsets.  
I actually got things to work better by using a difference of the ancestors() function:

  hg churn -r "ancestors(TagB) - ancestors(TagA)"

which gives me counts for R3, R4, R6 and R7.  (it's a bit weird that the ancestors of a changeset include the changeset itself, but it sure is convenient here)


> > I'm guessing that the structure of the repository is confusing it.
> > Although the R6 has a larger revision number, it actually happened
> > earlier, chronologically speaking, than R3.  For some reason
> mercurial
> > decided to rearrange the revision numbers to this more confusing
> order.
> 
> Given the DAG you depicted above, this is confusing. How can the merge
> R6 happen before R3 was created? Do you mean the recorded commit date?

Sorry, I had a few more revisions in there originally and didn't update my paragraph when I trimmed them out.  
I actually meant to say "Although R*5* has a larger revision number ..."


> Keep in mind that the order of changesets in your repository is
> reflecting the chronological order of pulling them in, not the order of
> how they were created somewhere else. This means that the incremental
> id is NOT unique across clones. Only the hash is...

Yes, I know, thanks for the reminder.  This is one of the reasons why I'm using tags.

> 
> > So, I have three questions:
> >   1) Is it a bug in churn that it can't handle this?
> 
> I've not understood the "this" from your description properly yet, but
> I tried a similar setup here, and can say that churn works as expected
> for me.

Well, "-r x:y" doesn't mean quite what I through it did, so churn was doing the right thing.
It seems like using the ":" operator is not all that useful in most cases, especially with mercurial's way of assigning revision numbers.


> >   2) Is the fact that the revision numbers aren't even vaguely
> > chronological a bug?
> 
> If you think that they should reflect the date the revisions were
> created, you misunderstood the meaning of revision numbers in
> Mercurial. It is no bug.

Ok.  It just makes for some really hard to understand graphs.  Perhaps the graph view shouldn't sort by rev num, or would that be too hard to do?

> >   3) Is there a way to force mercurial to renumber the changesets in
> a
> > better order?
> 
> Yes, you can convert your repository with the --datesort option. "hg
> convert <source> <clone> --datesort". This will simulate what happens
> if you selectively pull in changesets according to their date.

Ah, thanks.  I tried that, but had some problems.  I sent a separate email about that.  ("Identical change, different changesetid")

eric