[PATCH] hgweb: follow renames and copies in file log (issue1576)

[Matt Mackall]

On Wed, 2011-04-06 at 17:03 +0200, Dirkjan Ochtman wrote:
> On Wed, Apr 6, 2011 at 16:34, Kevin Gessner <kevin at fogcreek.com> wrote:
> > # HG changeset patch
> > # User Kevin Gessner <kevin at fogcreek.com>
> > # Date 1301949717 14400
> > # Node ID 6df5de9f4dcbb71c4654a8d1c3181a96194d8579
> > # Parent  086c9f203a53ee4b20a83d06c6e966ecc8a30cbf
> > hgweb: follow renames and copies in file log (issue1576)
> >
> > When walking the requested filectx finds a rename or copy, recursively walk
> > that filectx, adding as many changesets as needed, and following renames.
> >
> > Links to older revisions must include the path that the file had in that
> > revision, so revnavgen and nodefunc must return path info from the correct
> > filectx.
> >
> > diff --git a/mercurial/hgweb/webcommands.py b/mercurial/hgweb/webcommands.py
> > --- a/mercurial/hgweb/webcommands.py
> > +++ b/mercurial/hgweb/webcommands.py
> > @@ -631,21 +631,34 @@
> >     morevars = copy.copy(tmpl.defaults['sessionvars'])
> >     morevars['revcount'] = revcount * 2
> >
> > -    count = fctx.filerev() + 1
> > -    start = max(0, fctx.filerev() - revcount + 1) # first rev on this page
> > +    def follow(fctx):
> > +        l = []
> > +        while fctx:
> > +            l.insert(0, fctx)
> > +            renamed = fctx.filectx(0).renamed()
> > +            if renamed:
> > +                fctx = web.repo.filectx(renamed[0], fileid=renamed[1])
> > +            else:
> > +                fctx = None
> > +        return l
> > +
> > +    allfctx = follow(fctx)
> 
> Great that you're working on this! Some notes:
> 
> - This looks like it will repeatedly call list.insert(0, something),
> which is potentially a big performance liability. Inserting at the
> start of the list shifts all elements in the list to the right, so you
> probably don't want to do it in this kind of loop.
> 
> - This also looks like you will always follow the first rename in the
> history (calculated from the filelog's tip). Is that correct? I think
> we would only want to follow the last one, i.e. short-circuit by going
> to the first revision in this filelog and check if it was rename, move
> on to that filelog, check its first revision, etc.

Not sure if that's right. It doesn't handle the case where a file is
deleted and another is renamed in its place.

And frankly, now that I'm thinking about it more, I'm not sure if this
all makes sense in light of the way 'hg log file' works.

Consider this: if I ask "what did the President of the United States do
on Aug 21, 1959?", you can either say "he wasn't born yet" or "he was
admitting Hawaii into the union". Both of these answers are correct from
their perspective, but one is a hell of a lot more relevant. Also note
that one of these answers is constant, and the other changes wildly
based on when you ask the question.

These two perspectives can be called 'identity' and 'position'.
Mercurial generally takes the 'position' perspective, because it's _the
only perspective available_ to tools like compilers, which see things
through the window of the filesystem. So if I ask "what were the
contents of Makefile on Dec 8, 2008?", I will not be impressed if you
tell me it didn't exist yet. I'm obviously interested in what make(1)
would have seen on that date, and any deletions and renames aren't
relevant. 

This is why log favors the position perspective by default, and takes an
identity perspective when you give the -f flag. And the view we're
talking about here is basically the hgweb analog of 'hg log file'.

It's ok to add links at various points to say "this file came from here"
though.

-- 
Mathematics is the supreme nostalgia of our time.