[PATCH] bzr tracks permissions

[Denys Duchier]

John A Meinel <john at arbash-meinel.com> writes:

> Attached is a patch to have bzr include permission (mode, owner, group)
> into the inventory files.

(mode, owner, group) is eminently non-portable metadata, even across identical
operating systems.  I am not sure that it is a good idea to build rigid support
for it into core bzr.  Instead, I suspect it would be more generally useful to
address the issue of how to track arbitrary metadata.  I may be wrong, but here
are some thoughts on the subject anyway:

I see 3 main issues:

	(1) how to represent metadata
	(2) how to discover metadata changes in the working tree
	(3) how to apply metadata changes to the working tree

For (2) and (3), I believe that we could use plugins, but see below.

For (1) the most straighforward way (although not especially economical) would
be to represent metadata items as entries in the inventory with kind e.g.
"meta:PROPERTY" (where PROPERTY is the metadata property being tracked) and
parent the entry to which they pertain.

For metadata such as permission rights (etc...), it is clear that many
files/dirs will have the same ones.  Therefore, it would be wise to allow
different metadata entries to refer to the same text_id.

In fact, an easy (optional) compression method is to include the data in the
text_id itself; for example:

	text_id="data:drwxr-xr-x"

thus obviating the need for additional on-disk representation.

On the subject of (2), several options come to mind.  We do not have to pick
one.  Each could be useful in different circumstances, and different
contributors to a shared project may make different choices for their own
working tree (for example because they work on different OSes):

(2a) explicit change of metadata:

	bzr meta chmod="drwx------" DIR1 DIR2

(2b) implicit tracking of changes:

	plugins are run, during preparation of a commit, to determine all
	metadata changes

(2c) both, because we might want to track similar kinds of metadata differently
     for different OSes (simply because there might be no reasonable way to
     translate between them)

(2d) other ideas that I haven't thought of

It should be noted that, when we track metadata such as owner or group, we _may_
want to apply a _translation_ before exporting/importing changes.  This would
allow us to have _concrete_ owners and groups in the working tree, and
_abstract_ owners and groups in the vcs.  Mediation between abstract and
concrete would be ensured by plugins.

Does any of this make sense?

-- 
Dr. Denys Duchier - IRI & LIFL - CNRS, Lille, France
+33 (0)6 25 78 25 74    http://www.lifl.fr/~duchier/