Thoughts on file ids

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-05-03 10:35 AM, Jelmer Vernooij wrote:
> File ids have a couple of known issues; in particular (my pet peeve)
> they make parallel imports very problematic. They're also hard on
> foreign branch implementations which don't natively have the concept of
> file ids. And they're a blocker for file copies.
> 
> File ids currently seem to serve three fairly distinct purposes:
> 
> 1) as ways to get at files in the tree API
> 
> 2) as part of the keys to look up texts
> 
> 3) as a way to determine equivalent files between different trees in
> merges

That's about right, but 3) is about any operation involving 2 or more
trees, not just merges.

> As far as I can tell there is nothing in the API that should really
> require the file identifiers in these three cases to be identical, and
> these three use cases have distinct requirements:
> ]
> (1) and (2) strictly require file ids to be unique and refer to one
> specific file/path.

Absent (3), we'd probably just use the path for (1).  Using the path for
(2) would mean that renaming files without changing their contents would
take more space than it does with file-ids.

> (3) in theory doesn't, although the current
> implementation probably does.

I've long imagined that any identifier could be substituted in the merge
code without too much trouble.

> (2) requires file ids to be persistent across multiple runs of bzr. (3)
> doesn't - (1) probably doesn't, depending on whether we allow external
> users to access files by file id.
> 
> (2) seems like it could be a repository implementation detail, and not
> something that needs to be exposed at the API level.

The model should provide a way to refer to specific revisions of files,
and revision + (1) is a pretty intuitive way to do that.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3AeFoACgkQ0F+nu1YWqI1fegCfVtC5MgDIkqOBB1mArk6BWwX4
GfIAni+41Lz2XNEfrNkuWjI9Xa7J50rB
=z0uI
-----END PGP SIGNATURE-----