Proposal: use predictable file-ids

[Robert Collins]

On Thu, 2005-08-11 at 18:07 -0500, John A Meinel wrote:
> Just think about it. How are file-ids actually used in the source? I
> know they are stored in the inventory, and designed so that when you
> rename a file, it keeps its id, and then notes a rename when you commit.
> 
> Why not just note the rename at the time of "bzr mv". It made sense in
> arch, because it was part of the changeset format. And in arch a
> changeset is much more self sufficient. I can grab a changeset and apply
> it, without any further context. That isn't really a design criteria for
> bzr.

Actually its deeper than that. Consider delta storage : a single delta
per commit is very expensive to process when you want changes for a
single file over long time periods (i.e. annotate), as the arch design
showed - so we probably want a delta per file per change to the file.
This implies that we are able to associate the changes to that file
across renames - but without having to scan for those rename points (or
we go straight back to the arch costs of hitting every commit to
determine what happened there). 

File ids are very useful because they provide a direct index from any
commit to all variations of the same file, irrespective of renames,
other files with the same name, uncommitted local changes etc.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- 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/20050816/8b94bc25/attachment.pgp