[Monotone-devel] (non)-changes to manifest format

[graydon hoare]

hi,

yesterday we talked some about changing the format of manifests. the
motivating reasons were:

  (1) empty directories
  (2) directory renames
  (3) file permissions, ACLs, extended attributes

I've considered these in more detail, and decided against modifying
the manifest format. there is considerable benefit that a part of GNU
coreutils (sha1sum) can check the contents of a manifest, and I do not
wish to lose that. furthermore I do not wish to make the code more
complex, and a change to manifests would affect a lot of code.

empty directories are the easiest of these to deal with: I'm going to
carry on ignoring them. I don't care about them. some people believe
this is a bug, but I simply don't think they're worth the effort to
handle.

directory renames can be handled heuristically, I think in quite a
natural fashion. since empty directories are ignored, any directory
rename will also incur at least one file rename. if the file rename is
detected (which we accept as a task monotone should do relatively well
most of the time) then it can be classified into a file-rename part
and a directory-rename part, simply by looking at which parts of the
path changed (before or after the last slash). if it is a directory
rename, it can be registered as such in the patch_set used to analyze
edges, and applied to other edges when merging (eg. making files added
to the old directory get added to the new one instead).

finally, the sticky point: extended file attributes. I know "in
general" how I'm going to handle this now. but I am undecided on the
precise choice of technique. the general approach is to add a hook
which looks at (some) files listed in the manifest, and run this hook
after checkout, update and merge actions. the hook reads and
interprets one or more of the file's *contents*, and the contents
describe attributes of files elsewhere in the tree.

so, there are several options for this "special file" mechanism, and
the hook interface at monotone's level. the three axes I can see this
varying along are:

  - is the hook called for *every* file in your tree, given a chance
    to interpret it? or just called for certain files with special
    names?

  - is there a single special file in the root of the tree, or lots
    all scattered around the tree? (eg. an .attrs file in each
    directory)

  - is the interpreted file just more lua source? or is it a
    declarative data structure such as {filename, attrib, value}
    triples?

the easiest solution I can think of -- and am therefore inclined to
pursue -- involves one specially named file in the root directory
storing triples, such as:

$ cat .mt-attrs
configure       execute    true
debian/control  execute    true
COPYING         readonly   true
etc/passwd      owner      root

and a default lua hook which interprets a small set of attributes
sufficient to handle a handful of "important cases".

opinions? I know it's a bit of a hack, but a small hack which works is
much better than an invasive change which breaks lots of code and
makes everything more complex.

-graydon