Mon 21 Feb 2005 08:35:37 AM UTC, original submission:
Currently, it is not legal to concatenate the changesets 'delete_file "foo/bar"' and 'add_file "foo"', because the former implies the existence of a directory "foo", which conflicts with the existence of a file "foo".
Thus, the implicit semantics of monotone are currently: a directory D exists in revision A if some file in A has the form D/something, or if in some arbitrarily deep ancestor of A, there was such a file, and no "delete_dir D" appears on the changeset path between that ancestor and A.
This is pretty broken -- in particular, it makes the validity of history a decidedly non-local problem. (It's already a little bit non-local, because of the requirement that two arbitrarily long paths between the same two revisions must create the same changeset when concatenated along, but this is much worse.) We can never tell whether adding a file is valid without scanning the entire history.
I see two options (perhaps there are more):
-- decide that monotone supports empty directories. Add directories to manifests.
-- decide that monotone really means that emptying a directory implicitly deletes it, and somehow make concatenate("delete_file foo/bar", "add_file foo") work (without allowing any other badness that really is bad at the same time).
I kind of prefer the latter, as being the semantics I'm used to, and simpler to transition to; but I am cautious about how we can make that case legal without making truly broken cases legal as well.
|