#120 Preserve attributes in immutable directories
We've run into a use case where it's important to to
preserve file and directory permissions across
checkin/checkout operations (specifically keeping files
which are read-only from becoming writable). (This has
to do with a proprietary program which is used to edit
files in the working directory.) It seems to me that
the best way to do this would be to preserve all
attributes on mutable directory entries in immutable
snapshots of them. This avoids adding some other
method for storing this information, makes use of
existing code in the repository for handling access
control attributes, and provides a nice generalization
for storing arbitrary meta-data inside versions. Of
course there are several issues with implementing this:
- I believe we'd want to treat such attributes as
immutable. (That's not necessarily strictly required,
but it seems as though it would make for a far more
sensible model for the user.) Currently there's no
such thing as an immutable attribute.
- Replication would need to propagate these immutable
attributes along with immutable directories replicated
to remote repositories.
- Attribute changes in working copies would require a
form of copy-on-write for attributes (when the
attribute change is being made to an object which is
only in the immutable base directory). Actually, any
copy-on-write operation would have to copy both the
object being modified and its attributes. (A more
complicated option would be to allow part of the
storage of the attribute history to be shared between
the mutable and immutable objects, just as mutable and
immutable directories represent deltas of changes over
their base.)
- It could lead to user-hostile cases like checking out
a package and finding that some of its contents are
owned by a different user and not writable by you.
Probably we would want to prevent this from ever
happening, but maybe we should make it configurable in
some way in case someone does want to preserve this
level of information. One way we could do it is have
the snapshot operation accept a list of attributes to
filter out and have that default to {"#owner"} or maybe
{"#owner", "#group"}.
- This could lead to a significant increase in the
number of attributes stored by the repository.
Currently no effort is made to compress these and every
attribute name and value takes up space proportional to
its string length in the repository's memory space. It
might be a good idea to implement some form of better
attribute storage management (such as a global string
table) along with this. See the RFE #1075393
"Attribute storage space management":
https://sourceforge.net/tracker/index.php?func=detail&aid=1075393&group_id=34164&atid=410430
