[Fwd: [PATCH] bzr tracks permissions]

[John Arbash Meinel]

Gustavo Niemeyer wrote:

>Oops.. I missed part of your original message.
>
...

>>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.
>>    
>>
>
>I completely agree that generic properties sounds more interesting.
>Can you please help me convincing Robert and Martin about it? :-)
>
>Here is a discussion which happened a couple of hours ago between
>me and Robert, to give you some insight:
>  
>
...

I think I read through everything (I was kind of skimming). And this is
my take on the subject.

My "<meta-info>" aka properties tag was a generic hook for other people
to shove stuff that they care about, that *bzr* would not explicitly handle.
Basically, if it was in <meta-info> bzr would make sure to keep track of
it, and probably tell you about conflicts, etc. But it wouldn't
*understand* it.
My goal for meta-info was to enable people to write plugins/etc which
need to track per-file information, and want it revisioned.

The executable bit is different. I want bzr core to understand that bit.
Which is why I think it should get its own xml entry. So that you would
have something like:

<inventory>
<entry file_id="bzrignore-20050311232317-81f7b71efa2db11a"
       kind="file" name=".bzrignore"
       text_id="bzrignore-20050826023137-1ff5a95c8c33ddb8"
       text_sha1="306645ea65f4be1a5706d0cb5299d64a72e9c828"
       text_size="179" 
       executable="False">
  <meta-info>
    <unix-permissions>0644/<unix-permissions>
    <windows-acl>
      <group name="something">XYZ</group>
      <user name="jameinel">Full</user>
    </windows-acl>
    <nickname>The ignored file</nickname>
    <notes>Just a stupid file</notes>
  </meta-info>
</entry>
<entry 
...
</inventory>

The above points out that "executable" is just a property of an
inventory entry. The <meta-info> tag is for other people to care about.
The way I implemented it, it was a key-value dictionary mapping. So that
each key mapped into an arbitrary string. I never worked out merging,
but my idea was to treat all of the strings as *binary blobs*. So that
when you merge, if 2 entries have keys mapping to the same value, then
it would just be a simple binary conflict. No real merging.

This enables plugins, front-ends etc to have per-file meta information.
Right now, you have to create your own file, and put it somewhere, which
ends up looking ugly, and isn't mergable at all. I just want to give
people something that they can play with, not try and solve all the
world's woes. (Hence why merging properties is a conflict, rather than
something "intelligent".) I suppose long term, the merge code should
have a list of meta-info handlers, so that when it tries to merge
<meta-info><foo/></meta-info> it calls the "foo" handler.

So my basic view is that the Executable bit should be promoted to full
entry, since bzr core will handle it. Stuff in <meta-info> is meant just
to enable other things to do what they want.

John
=:->

-------------- 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/0c9f50ec/attachment.pgp