copy & rename support

[Matt Mackall]

On Thu, Jun 30, 2005 at 10:10:28PM +0100, Michael A Fetterman wrote:
> Guy A edits linux-2.6.11/foo-bar
> 
> Gal B moves the repo from linux-2.6.11 to linux-2.6.12, thus renaming
> all the files in 2.6.11...
> 
> Gal B pushes first.
> 
> Guy A pulls.  bk would know to rename all of Guy A's files, and still
> get the merge on linux-2.6.12/foo-bar correct.
> 
> To do this right, there's a level of direction between filenames and
> revision histories, just like in the unix filesystem (filenames point
> to inodes, which point to storage on the disk).

This particular indirection is a gigantic pain in the neck and I think
we may be able to avoid it. But I haven't thought through all the
details yet.

Currently, doing a copy/rename x->y stores "this file came from <x>"
in y.

This doesn't leave us with "where did <x> go?" info at x, as there
could be arbitrary amounts of fanout here. And there's really no
sensible place to stick the metadata anyway as there's no _data_ to
add to x.

But we can figure out where things went reasonably efficiently as follows:

to = {}
for each relevant child N' of revision N:
  for each changed file F in N':
    if F has no parent: # it's new, renamed or copied
      from = F.meta("rename", None)
      if from:
        to.setdefault(from, []).append(F)

..where relevant means that N' is on the path of the merge.

> For what it's worth, below is a patch for adding "hg copy" support to
> "hg rawcommit".  It currently does nothing more than allow rawcommit
> to add copies in the same way that "hg copy" does...

Nice. I'll think about this.

FYI, I'd kindof like to deprecate rawcommit and try to use
add/remove/copy/update/commit directly.

-- 
Mathematics is the supreme nostalgia of our time.