[RFC] Tracking file copies

[Jelmer Vernooij]

On Sun, 2006-06-18 at 17:51 -0500, John Arbash Meinel wrote:
> Jelmer Vernooij wrote:
> > 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.
> Both Mercurial and Subversion support copies, and as a result neither
> one of them supports merge after rename.
Ah, I knew there was a catch somewhere. I hadn't considered whether how
this would work with merge.

> 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.

[use cases]
> 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).
Yeah, Subversion has the same issue. Subversion files can be added,
removed, copied or "replaced" - that's the way they handle rename +
readd, which is a bit ugly imho, and very weird if you don't know what
problem it's trying to solve.

> 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 it would make sense to be able to record that one file was
originally copied from another - not necessarily say the two are the
same. That way, only one file (the original one) is candidate for the
merge.

I am mainly interested in this information as metadata - so it can be
imported from and exported to other version control systems. It might
also help in terms of storage for some storage backends (in the case of
weaves, keep both files in one weave?).

The reason I'm looking at this for Subversion is that it might help me
to get rid of the revision cache I'm currently keeping. I need to
traverse history in order to find the proper file id, even for files in
the latest revision. File id aliases, might also be of help here,
instead of copies.

> 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.
Just tracking the information wouldn't really hurt, though? It would
come in handy for roundtripping.

> 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.
Thanks for the reply. I'm just considering what the best solution would
be to improve performance of the Subversion plugin. Caching the revision
history doesn't take long (about a minute for 16000 revisions here, and
it never expires), but it's not really neat to have to keep a cache.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060619/3304c7fd/attachment.pgp