[Fwd: [PATCH] bzr tracks permissions]

[John Arbash Meinel]

I'm sending this to the list so that people are aware of what is going
on, and to reopen some old discussion, now that bzr has progressed.

>Hello John,
>
>I'll try to implement the 'x' bit support on bzr, and I've seen in
>the list Robert answering to a message from you, which would
>probably contain code to track permissions on bzr. Unfortunately,
>I don't have the original message.
>
>If possible, can you please send me that message? I'd like to
>see how you implemented it.
>
>Thanks,
> -- Gustavo Niemeyer http://niemeyer.net
>
Here's a forward of my original message. Since this was written in June,
I have the feeling it won't apply at all to the current bzr. But you
might try. :) The attached "add-permissions-to-inventory" is the
associated patch.

>Attached is a patch to have bzr include permission (mode, owner, group)
>into the inventory files.
>I have checked that it works with "bzr status" and "bzr commit".
>testbzr passes, though only with python2.4 (since python2.3 requires all
>modules to actually have tests, not my error, currently the error of
>bzr-mainline rev635).
>
>I haven't figured out how to include the information that permissions
>have changed. Also, it is certainly likely that some things like
>owner/group should not be committed all the time. (It means that when
>you do an rsync of mainline, it will look like every file has changed
>since it has a new owner & group).
>
>Mostly I just wanted to get this patch out to get some feedback.
>Especially how to handle user/group issues.
>
>I'm thinking that it might be best to include user&group in the commit,
>but if they are different, it isn't considered a 'diff'.
>
>We could also just not revctl user/group at all, and let higher-level
>pieces support that. Or have it be an options flag inside the tree. I
>think I favor the options flag. So that someone who wants to revctl /etc
> or $HOME can do so. But by default the only bit that is checked is the
>execute bit.
>
>Also, this also needs merge() to be updated, so that it will also merge
>the permission bits.
>
>John
>=:->
>

This was my "Permissions" work, which attempted to add a <permissions>
field to all inventory objects. This was not followed through with,
because it was felt that the full owner+group+mode was not portable
across machines, much less across platforms.

I have a later patch for "bzr meta" (meta-data-in-inventory.patch),
which adds a single open-ended text string which can be used for
whatever you want.
The idea was that front-ends which wanted to be able to handle things
like permissions, could use "bzr meta" (or its library equivalent) to
get and update extra information about a file.

This is the contents of the other message:

>Martin Pool wrote:
>  
>
>>> On  9 Jun 2005, John A Meinel <john at arbash-meinel.com> wrote:
>>> 
>>> 
>>    
>>
>>>>>What about if each <inventory><entry> tag has an optional child named
>>>>><meta>.
>>>>>So that each InventoryEntry object has a meta property. This could
>>>>>probably be a Meta object. I would generally say that bzr shouldn't care
>>>>>what is in it, as long as it reproduces it accurately between revisions.
>>>>>(Meaning Meta could just contain the text string, or a cElementTree
>>>>>object, or whatever, just as long as it got properly serialized with the
>>>>>to_element/from_element commands).
>>>      
>>>
>>> 
>>> 
>>> Yes, I'd like something like that.  Perhaps something along the lines
>>> of subversion properties.  Although I do think svn over-uses them for
>>> example by storing ignore lists.
>>> 
>>    
>>
>
>As you wish. See attached patch which provides a "bzr meta" command.
>This command lets you set/query for meta information contained about a file.
>Meta information is just a set of key->value pairs stored as:
>
><entry blah blah blah><meta>
><property name="key">value</property>
></meta>
></entry>
>
>Internally, Meta objects just contain a "properties" dictionary, keeping
>track of all of the key->value pairs.
>Because they are parsed into a dictionary, it is possible to identify if
>one Meta object is equivalent to the another one. Which is all you
>really need to have bzr commit/status/diff work.
>I don't really know what to put into diff, so right now, I just put
>## Meta-info modified
>
>I suppose you could at least put the keys that were modified, or
>possibly include the actual changes. But since 'value' can actually be
>multi-line, or even binary data (though it probably needs to be base64
>encoded first), I didn't really want to just print it to stdout.
>
>John
>=:->
>  
>

I think the meta command is a generally useful thing (it is kind of like
svn properties). Basically, it lets people add arbitrary strings to a
files inventory, which will then be tracked as time goes on. It could
certainly be used to add permissions handling.

I think that the 'x' bit, could probably be handled by adding an extra
field to the Inventory XML, namely "<executable/>". And this should be
handled in the core of bzr, so that merge will check and apply (or
unset) the executable bit when appropriate.

The goal of "bzr meta", though, was so that someone could write a
plugin, which could do full mode,owner,group permissions (or ACLs). That
sort of thing wouldn't have to be in the core, but currently the only
way to support it is to keep a separate versioned file (eg,
$wd/.bzr-permissions), rather than having things versioned per-file.

So my meta-info patch was more of an enabling thing. Probably my
add-permissions patch is a dead end. But it might lead to something for
the X bit.

John
=:->



-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-permissions-to-inventory.patch
Type: text/x-patch
Size: 10525 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050921/c2935629/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meta-data-in-inventory.patch
Type: text/x-patch
Size: 10735 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050921/c2935629/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050921/c2935629/attachment.pgp