[RFC] Tracking file copies

[Johan Rydberg]

John Arbash Meinel <john at arbash-meinel.com> writes:

>> 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?).
>
> [...]
> Are you wanting to create a new separate file
> (.bzr/repository/file-id-copies.knit), or just as a revision property,
> or just as a record in the knit index, or ...

Having a separate versioned file for it would probably be the
simplest, storage wise.  But we would have to extend our interfaces to
support it, which I feel could become quite ugly.

We could have had versioned file ids; where a file is identified by a
<file-id, version> tuple.  If you copy the file, the version is
increased.  But that would make merge hard as well (merge two
revisions that both have copied the same file, but for different
reasons).  And it would require extensive surgery to our code.

Also please consider history formats that does not have the notion of
"versioned files", e.g., blob formats.

~j