[PATCH] add rename information handling to annotate

[Robin Farine]

On Wednesday December 28 2005 18:27, Matt Mackall wrote:

> Rename information is only recorded at the file level. So it's
> too expensive to look at each file when doing a project-wide log.
>
> The presence of renames can be guessed from looking at manifests.
> This is moderately expensive.

> We've got a similar performance problem for deletes which needs
> solving, possibly by extending the changeset format. But it
> wouldn't be backward-compatible, so I've been holding off on it
> in hopes that a better solution will appear.

Ok, copy information is recorded in filelogs while add & delete 
operations can be deduced from two consecutive manifests, right? 

So, instead of extending the changelog format, we could add a new 
log tracking file identities (say "idlog") where each record 
gathers the add/delete/copy operations associated with a record in 
the changelog.

This new log acts as a cache, it can be deleted and reconstructed 
based on the changelog and the filelogs. This would not introduce 
any incompatibility with older Mercurial repositories, just a one 
time delay when the "idlog" is built.

> > I am afraid to not be familiar enough with Mercurial internals
> > to figure out the cost of such a thing and how to handle corner
> > cases like a revision with a combined rename and copy such as
> > "hg rename a b; hg copy c a". This makes me wonder whether it
> > is worth recording copies rather than just renames since a copy
> > can be seen as a fork in the history of file...
>
> I'm not sure what people have against copies. They're a useful,
> general concept, and a proper superset of renames.
>
> Consider the example I started with - a few months back, I split
> the file hg.py into half a dozen pieces. Now I could have just
> created a bunch of new files and cut and pasted code into them.
> But with hg copy, I've actually recorded where that code came
> from and annotate will eventually be able to give me the history
> of each line in each "fork" in a meaningful way.

Personally, I have nothing against recording copy operations, and 
you gave me a good example of how it can be useful. I was just not 
so sure how to realize this kind of thing; if it is generally 
possible to decide where copied pieces of a file have been 
distributed into the copies.

Robin