[PATCH STABLE] log --follow shouldn't depend on the working dir context

Patrick Mézard patrick at mezard.eu
Tue Jun 12 07:39:10 CDT 2012


Le 11/06/12 22:39, Christian Boos a écrit :
> Hello,
> 
> I noticed that the change 60101427d618 (released in Mercurial 2.1.1)
> introduced a check for "log --follow", verifying that the file examined
> is present in the parent context, so that revisions in the filelog
> can be followed from the appropriate starting point.
> 
> See http://www.selenic.com/hg/rev/60101427d618 for details.
> 
> This is all well and good except for the change's notion of parent
> context: it uses the working dir context for that!
> This breaks a number of things, like in my case the mercurial plugin
> for Trac which can operate on repositories having the null rev as the
> working dir revision. I'm sure it can also break other tools, like the
> hg command server in the same situation, and it even breaks "hg log" itself if you try something like:
> 
>   "hg log --follow file_only_in_branch_B -r branch_B"
> 
> when you're not on branch_B.
> 
> After discussing the matter with Patrick on IRC this morning,
> he agreed this was indeed a problem and suggested the following fix.

To clarify a bit, I agreed the lack of "peg-revision" is a long standing issue with log command when specifying file names, and threw this fix before vanishing away.

I do not like this fix because this is just a hack. Say file "foo" exists in revision r1 but not in revision r2, the following will now work:

  hg log --follow foo -r 'r1:r2'

but not this:

  hg log --follow foo -r 'r2:r1'

So the query output content depends on the revision order. This is surprising, only the output order should depend on the revision order.

Your problem is "foo" is implicitely defined as "foo" in revision ".". What you want is a way to say: "I want information about the thing called 'foo' defined in revision X over the revision range Y". Subversion supports this like:

  svn log -rY foo at X

We need a way to specify X, with a silly option like --pathrev if we cannot find a better one. Then we have to resolve this name for each revision in Y, which usually reduces to resolving the name in each "head" of Y. The problem is it is cheap to find the names of "foo" in ancestors of X, more expensive to do so in descendants of X. The second problem is it means refactoring walkchangerevs() to achieve this while we really want to replace it with a version or another of graphlog.getlogrevs().

--
Patrick Mézard


More information about the Mercurial-devel mailing list