[Fwd: [PATCH] bzr tracks permissions]

Wed Sep 21 16:56:24 BST 2005

Oops.. I missed part of your original message.

> 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.
[...]
> 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.

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:

<lifeless> niemeyer: how are you going ?

<niemeyer> lifeless: I'm doing fine.. the rolling checksum seems to be
working reasonably, even though a lot of testing is still needed.

<lifeless> niemeyer: ok. I'm very keen to get X bit rolling :0

<niemeyer> lifeless: Yesterday had a look at a possible new diff
algorithm that should improve the size of branches.
<niemeyer> lifeless: And started looking at properties as well
<niemeyer> lifeless: Which should be a way to handle the X bit you're so
keen about..

<lifeless> niemeyer: well. if we want general properties, then dublin
core is a good place to start.
<lifeless> but I think both Martin and I are thinking about executable
bit support as a much simpler thing, without the infrastructure
ramifications general purpose properties entail.
<lifeless> theres already a patch that tracks permissions and mode, that
can be trimmed down, reviewed for completeness etc.

<niemeyer> lifeless: Well.. I think it's the other way around, probably.
The dublin core is nothing more than generic properties attached to a
given entity.
<niemeyer> lifeless: Understood.. but wouldn't it be nice to implement
it as a property, given that it is really a property?

<lifeless> not really.
<lifeless> properties in a general sense involve a large number of
complications:
<lifeless>  * merging
<lifeless>  * representation on file systems that can support them
<lifeless>  * canonical representation
<lifeless> ...

<niemeyer> lifeless: So we won't be merging the X bit?
<niemeyer> lifeless: Nor represent it in file systems that support it?

<lifeless> so, its about 10 lines of code to write merge for x bit, and
incorporate it into our existing infrastructure
<lifeless> its probably at least 50 to do a general property registry,
mechanisms to register property types, and then hook that into merge

<niemeyer> lifeless: I have absolutely no doubts that doing something
specific is easier.

<lifeless> so I'm not against properties : I just think we need to focus
on the ball of right here, right now, and deliver the functionality
people needs.
<lifeless> after 1.0 would be a great time to generalise what we have
now to make it able to handle $random things.

<niemeyer> lifeless: Argh..
<niemeyer> lifeless: That's bad..

<lifeless> how so ?

<niemeyer> lifeless: Doing something ad-hoc to deliver it right now
rather than thinking about the right way to implement feature.
<niemeyer> the feature even

<lifeless> mmm
<lifeless> I'm in another meeting right now, I'll pop back when its over
to give this due focus

<niemeyer> lifeless: We need to merge, we need to integrate, we need to
implement ways to change the X bit. That will all be needed for generic
properties as well.
<niemeyer> lifeless: Ah, ok..

<ddaa> *boxing match mob screaming*
<ddaa> On my left, lifeless, champion, fighting XP.
<ddaa> On my right, niemeye, challenger, fighting BDUF.

<lifeless> haha
<lifeless> I was just thinking, that sounds like a BigDesign proposition

<ddaa> Not always a bad thing.

<lifeless> niemeyer: so, what you say is true. But there are several
questions here...
<lifeless>  * Do we have enough experience with this to generalise Right
Now ?
<lifeless> (generalise and GetItRight)

<lifeless>  * Can we do a tasteful solution to the problem in front of us? If we do what are the costs to migrate that to the PermanentSolution that may be around the corner ?

<niemeyer> ddaa: Not BDUF at all..

<lifeless>  * What do we expect the gap to be between doing the problem
right now, and doing the generic solution with a specific thing in it
for the current problem.
<lifeless> niemeyer: I'm back, btw

<niemeyer> lifeless: The experience we have to generalize is the same we
have to implement a single property

<lifeless> niemeyer: so, doing general properties means solving a number
of problems we dont need to solve to do the x bit.

<niemeyer> lifeless: Can you please list some of them?
<niemeyer> lifeless: Merge is needed, representation is needed, changing
commands are needed.
<niemeyer> lifeless: Versioning is needed

<lifeless> niemeyer: sure. For instance, merging two properties when the
version of bzr being used doesn't have the plugin for the property type

<niemeyer> lifeless: plugin for the property type?
<niemeyer> lifeless: What is that? :)

<lifeless> so in a sense this comes down to a definition of property. We
*have* properties on files now - sha1, content, length, last changed
revision, symlink_target
<lifeless> we don't have *arbitrary* properties, which is what I presume
you are talking about.

<niemeyer> lifeless: Properties in svn for instance, are text.
<niemeyer> lifeless: Yes, that's what I'm talking about.

<lifeless> arbitrary properties will have their own rules, per class of
property about merging. some will merge like files, some will merge in a
binary manner - all or nothing, others wont follow merging at all

<niemeyer> lifeless: That's BDUF :)

<lifeless> I think that doing this is a really good idea, but not until
we have delivered the core functionality. Which we haven't.
<lifeless> niemeyer: I have use cases, and am avoiding designing because
I can see it would be big

<niemeyer> lifeless: What I'm trying to avoid is implementing something
ad-hoc, which will pass through all the problems we'll have if we were
implementing something generic.

<lifeless> niemeyer: which is why I am reacting here to 'x' bit becoming
'properties'. Because I don't think that that is needed or appropriate.
<lifeless> niemeyer: I don't assume that it will pass through the same
problems. And we have code already (symlink) which will be nearly
identical to 'x' bit
<lifeless> for instance, properties dont magically change when the file
they are attached to is changed. And you dont need to know about
properties to work with symlinks and chmod.

<niemeyer> lifeless: And how do you handle these properties on systems
that don't support them?

<lifeless> niemeyer: they are stored in the working inventory when it is
created, so they are not lost. I have to do a (small) patch to symlink
to not create or delete symlinks on windows
<lifeless> I plan to get on that tomorrow in fact
<lifeless> now I've got this async thing behind me.

<niemeyer> lifeless: Now we'll do the same thing for the executable bit..

<lifeless> niemeyer: right, which is 2 strikes towards 'refactor and
generalise'

<niemeyer> lifeless: Yep.
<niemeyer> lifeless: Basically we're implementing something we know it's
a bad choice, to refactor later.

<lifeless> so you know the TDD mantra ? Red, Green, Refactor ?

<niemeyer> lifeless: There's people asking for storage of group/complete
permissions already..
<niemeyer> lifeless: One more item..

* niemeyer has a phone call..

<lifeless> tests fail, tests pass, remove duplication.

* niemeyer is back

<lifeless> so.
<lifeless> what I'm saying is that the thing we have enough info to full
implement right now is just the x bit, with appropriate care to make it
easy to generalise, code reuse with symlink et al et al.
<lifeless> I don't agree it would be a bad choice or the wrong thing.
<lifeless> in fact, given that you might implement properties as just
xml attributes in the inventory, the chances are that you would
implement executable support _precisely_ as you would after doing
properties.
<lifeless> except that it wouldn't be _called_ properties, and the
mental focus would be on the task at hand.
<lifeless> However, if you absolutely believe you'll do a better job
doing generic properties first, I'm not going to force you to do
something you think is substandard.

<niemeyer> lifeless: Nope.. the only thing needed would be applying
changes to/from files in the working copy. Merging, storage, etc, would
all be there for free.
<niemeyer> lifeless: Same thing with symlinks
<niemeyer> lifeless: Same thing with groups/etc..
<niemeyer> lifeless: But..

<lifeless> niemeyer: well given that groups etc apply to disk, what if I
with a previous version of bzr that doesn't have group support yet use a
bzr tree that does?

<niemeyer> lifeless: You're the one coordinating here. If you want me to
implement a specific thing to handle just the executable bit, that's
what I'll do.
<niemeyer> lifeless: It's a property..
<niemeyer> lifeless: A text property

<lifeless> does it fail ? does it preserve it? does it get it wrong? do
we have to bump the tree version when we add support for any new
property? How can it tell that property X requires $$$ thing to support
it

<niemeyer> lifeless: If bzr doesn't know what to do with them, it just
stores, and merges as usual.

<lifeless> Hah, and that is *wrong*.

<niemeyer> lifeless: Works quite well with svn

<lifeless> which is precisely why I don't want us to do properties until
we have at least a couple of other well designed and implement
specific-case things under our belts.
<lifeless> niemeyer: thats because svn doesn't do merges :)

<niemeyer> lifeless: In what sense?

<lifeless> niemeyer: so. how about this. Implement the code to do x bit,
which will give you a sense of the whole code base and whats where.
<lifeless> we won't merge that immediately, Instead we can talk about
generalising it and symlink into an entry level property system, reusing
the code etc. But only after the 'x' bit code has been tested and
written.

<niemeyer> lifeless: Ok, will do that.

<lifeless> niemeyer: deal

-- 
Gustavo Niemeyer
http://niemeyer.net