[RFC] Tracking file copies

[John Arbash Meinel]

Jelmer Vernooij wrote:
> Hi,
> 
> At the moment, Bazaar does not support tracking file copies. Are there
> any plans to support this in the future or strong objections against
> supporting it? 
> 
> Depending on how it would be supported, file copies could make life a
> lot simpler for the foreign branch plugins (both Subversion and
> Mercurial support copies). 
> 
> I'd like to start working on a spec for this, if nobody objects to
> supporting tracking file copies.
> 
> Cheers,
> 
> Jelmer
> 


Both Mercurial and Subversion support copies, and as a result neither
one of them supports merge after rename.

It is something that has been discussed a bit in the past. You may want
to look in the archives for stuff like id aliases, etc.

The primary reason merge-after-rename is difficult with copies is that
technically you have 2 files which are both valid targets for the merge.
There are thus many heuristics that could be applied, and all of them
fit a certain use case.
Some reason's people might think they want to copy:
1) I'm copying a template, (probably a fix to the template shouldn't
propogate, but maybe you want to update all the Copyright headers).

2) I'm spliting a file into multiple files, (now I have N files for N
classes, and if I make a change in one of those classes, it should merge
into the same class)

3) I'm creating a new driver which is only loosely based on this other
driver (updates should probably not propogate)

4) I'm creating a driver which is *strongly* based on this other driver.
(bugfixes in one should propogate to the other)


As far as I know, hg doesn't actually do anything with copies (yet).
They record it, but their annotations don't trace back, and they're
trying to figure out how to get a rename extracted from a 'copy+delete'
pair. (Ignoring cases like renaming A out of the way and putting a new A
in its place, or renaming A => B, and B => A, etc).

I think a better thing to spend your time on is figuring out what you
actually want to be able to do with copies. And work out how to make
that happen. I could see having a file copy over its annotations from
another knit. So that you still see the documentation about why/who
changed a line.

I think we might be able to do some neat things with a 'file_id X,
copied from file_id Y'. But adding the ability to copy files can
*really* complicate the model.

I'm not specifically trying to scare you off. I would be very interested
in reading a potential spec. But I do want to warn you about some
potential pitfalls.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060618/061f8677/attachment.pgp