[Fwd: [PATCH] bzr tracks permissions]

[John Arbash Meinel]

Aaron Bentley wrote:

> John Arbash Meinel wrote:
>
> >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.
>
>
> Funtamentally, I don't think there's a big difference between core and
> plugins.  If you ship a plugin with the rest of bzr, it's core.


I sort of agree with you. My feeling is that there are things that you
*have* to have in a version control system. Things that everyone pretty
much agrees with that they want. Stuff like being able to get back old
versions of the files, merging, etc. In my mind, this is the *core* 
functionality, and should exist in bzrlib.

Then you have things that only some people want. And this is where
plugins, etc, come into play.

My goal with meta-info was to provide a playground for people developing
optional components. Right now, there is nowhere to put things, so I was
creating a namespace for optional functionality to store its information.

To me, the executable bit is a core functionality. Everyone who runs bzr
should have the executable bit properly tracked, and its effect should
be felt by the merge routines. (Merging someone who made a file
executable should make your file executable).

>
> I did an executible-bit version a while back, and I based it on
> properties.  I also handled the is_text property, so we can avoid doing
> diffs or textual merges on non-text files.

text/not-text might also be considered a core function. I'm not really
sure. This brings up the whole encoding issue, though, along with
file-ending stuff. I still like that tla didn't try to be magical about
line endings, or file encodings.

>
> My sense is that we quickly run into code duplication.  Better to have
> one set of code.  In particular, windows users will need a way to
> control the execute bit, and it would be nice to have just one command
> to set any property.
>
> For each property, you'd be able to supply
> - a way to verify and canonicalize values
> - a to determine values (e.g.,lstat for POSIX, and inventory or default
> value for Windows)
> - a three-way merger
>
> This allows you to write full POSIX permission support or anything else
> in exactly the same way.

So why not get rid of everything in the current <inventory><entry>
stuff, and just convert it all into properties, and do the same thing?
I'm not really sure what a 3-way merge operation should look like for
"text_size" but that is certainly a property of a file. Same thing for
text_sha1, etc.
Even "name" can be thought of as a property, and a three-way merger
would mean the file needs to be renamed.

I'm just trying to point out that while there is some redundancy in how
merging is done, where certain properties are treated differently than
others, I think it actually makes sense, because conceptually, different
properties have a different level of significance and meaning.

I would say that the necessary pieces are:
- a way to verify and canonicalize values
- a way to determine values
- a three-way merger
- a way to apply the value

Unless you consider applying the value to be part of merging.

Could the above 4 things do the type of things that we would like? Most
likely. I just don't know if it is the best framework to think about
things, or not.
In some ways, it is elegant to have the same pattern applied to all the
meta information that you have to about a file.

John
=:->

>
> Aaron

-------------- 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/1517b2ef/attachment.pgp