[Fwd: [PATCH] bzr tracks permissions]

[John Arbash Meinel]

Aaron Bentley wrote:
> 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.

At what level is it pluggable? Just that the merge_core function takes
callbacks?

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

Can we autodetect this at the time of trying to merge?
Although I'm not opposed to having a "use merge algorithm" field, where
it can be "binary merge", aka fail if there are differences.

It might be interesting to have a sort of property, which is a list of
preferred merge methods. So you could start with "xml_merge" if it is
available, and then fall back to "text_merge", etc.
You could even conceivably want a C++ merge, which would understand
source code better, and not merge code into a different function.

I do think that you would want fallbacks, though. So that you can use an
alternate if one is not installed.

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

Well, text_sha1 and text_size both require the file contents to have
already been merged.

While other properties might actually dictate the merge algorithm used
on file contents. (Such as your is_text property).

I'm wondering about a sort of "priority" for the pluggable merge
algorithm. So that some would happen before the contents are merged, and
others would happen after.

Though as I think of it more, the file-contents merge algorithm should
actually just be some sort of "MetaMerge" that would look for and read
the "is_text" field before deciding which real merge algorithm to use.

John
=:->

> 
> 
>>>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
-------------- 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/60030a63/attachment.pgp