Thoughts on file ids

[Robert Collins]

This isn't a concordance of all the issues, and verification is probably needed.

The last time I test this, git and hg handle simple directory renames
fine. Its complex cases like:

common history : directory d, files d/a d/b
in branch A:
 rename d/a to /a
in branch B:
 rename d to e

expected outcome: /a is unaffected when merging B to A, and e/a is
moved to /a when merging A to B.

Then we can parameterise it further, and in A also modify /a. Or in B
also modify /b. Or modify them both.

I don't seem to have the set of permutations I put together the last
time this came up at hand, but you can generate the whole set: its
basically the cross product of various dimensions:
rename containing directory [no, yes to unique, yes to conflicting]
child rename [no, yes out of the subtree, yes within the subtree, yes
to identical name in other tree]
child type [file, directory[empty], symlink, subtree, directory[with children]
child modifications [none, conflicting contents, identical contents,
nonconflicting changes, change-type]
executability bit [unchanged, change on side, change identically on both]
change granularity [one-thing-per-commit, all-at-once, combinations-thereof]
merge granularity [merge all changes, merge only some changes [space
splitting], merge only some commits [time splitting]

There may be more dimensions, I'm don't recall if that was sufficient
or not. For each unique combination we can assert what the resulting
tree should look like, including whether there are conflicts detected
or not.

I will say that its pretty hard when a file /d/a is renamed to /foo
and becomes a symlink, to merge that properly for systems that don't
track renames as first class objects. hg kindof does (in that it has
metadata saying 'foo was renamed from bar'), and git doesn't (but
perhaps is adding it in its lookaside datastructures nowadays).

-Rob