Comment 3 for bug 269095

To refine my last posting, if "bzr cp" accepts a "file-ids-from" option just like "bzr add" does, this would even allow to add files from different, otherwise unrelated repositories to an existing repository!

In the current implementation of bzr, "branches" and "repositories" are just organizational boundaries between projects which determine where the revision history is physically stored.

But from a conceptional point of view, it should be possible to merge any existing repository from any user from any site into a large, shared single one, because it is revision-ids and file-ids which glues the revision graph together, and not branch location or repository location.

And revision-ids as well as file-ids are unique identifiers in space and time.

This would allow, for instance, to use the same file-id for a text file "GPL" regardless of the repository, and tools could make use of this fact to retrieve an inheritance graph of this file across a set of otherwise unrelated repositories.

Thanks to "bzr add --file-ids-from" this already works in a limited way when moving files across repositories: A file might be removed from a repository and added to a different one using the same file-id.

While the past history of the file remains physically in the first repository only, a third-party tool can easily extract and combine the histories of the file from both repositories and display it, because it is always possible to associate the related files from both repository using the identical file-id.

A command "bzr cp" would make the same possible *within* a single repository, which is quite impossible now. For instance,

$ bzr add GPLv2
$ bzr ci
$ bzr cp GPLv2 GPLv3
$ "$EDITOR" GPLv3
$ bzr ci

would reveal that that GPLv3 is a modified copy of GPLv2 as of the previous revision, but from now on both files will evolve independent (with different file-ids).