[Fwd: [PATCH] bzr tracks permissions]

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
>>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.
...
> 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).

So merging is actually pluggable in current bzr.  You have your choice
of diff3 or merge3.  And when weaves come, you'll have weave merge too,
probably as the default.

And while the execute bit is useful to us, it's definitely not useful to
a Win32 programmer.

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

If you perform a textual merge on a file whose binary contents aren't
ASCII or a superset, the results are really unlikely to be useful.
Secondarily, you shouldn't send control characters to the terminal by
accident.

So yeah, I feel it's core functionality.

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

This would be pretty neat.  For example, merge already does three-way on
filenames-- this would just make the code shorter.  For dependent
properties, like text-sha-1, text-size, the get-merged-value routine
would have to look at the file contents, which is pretty weird.

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

Yeah, and I'm just saying many of those differences can be handled
decently by specializing a few things, and letting the defaults handle
the rest.

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

I was, but it probably makes more sense to split it out.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDMcJH0F+nu1YWqI0RAvI3AJ41M4j074Wjghx0sbt2NhSsnV1ACgCcDmfT
81CfqcaW+wFeAWA/Od7yz4c=
=2Duh
-----END PGP SIGNATURE-----