[MERGE] line-endings support: part 1 of 2: versioned properties

[Alexander Belchenko]

Neil Martinsen-Burrell пишет:
> Alexander Belchenko wrote:
>> Accepting only filemasks in the form '*.ext' is deliberate decision.
>> Because if I will allow to using something like:
>>
>> dir/subdir/*.c
>>
>> Then I'll get potential problems with renames/moves. And I don't want to
>> have this pain.
>>
>> No, I think restriction for *.ext is right here.
> 
> In what sense do you not need to deal with renaming now?  Consider the 
> hypthetical sequence of commands:
> 
> bzr prop-set bzr:special-property 'special value' '*.txt'
> bzr add help.txt
> bzr ci -m ''
> bzr mv help.txt help.rst
> bzr ci -m ''
> # does help.rst have the appropriate property set still?

No.

Although your example is make sense for me, but I think the users
less likely tends to changes *extension* of file name rather than *basename*,
or parent dir. This is why I think my approach will works for 90-95% cases.

Even if user decides to rename help.txt to help.rst then it's most likely
he/she decides to rename and all others txt files to *.rst. The transition
will be made once for long time.

> It seems like wildcarding property values will always have the problem 
> of renaming losing properties, unless you deal with it explicitly.  I 
> think that properties should conceptually be a mapping from file-ids to 
> vpdicts.  If this is implemented by referring to some collection of 
> file-ids in terms of a glob pattern, that's fine, but it shouldn't break 
> the conceptual abstraction that versioned properties adhere to file 
> objects.  

Yes, as I wrote in my first mail with merge request:

"I understand that my VP design is not the best possible. As I said I need simple
code that I could finish in short period of time and I did it."

Any approach has its own pros and cons.

You wanna ideal solution? I don't have it. I have simple solution. And simple solution
will always have limitations and tradeoffs. I can live with this.

I'm deeply understand almost all limitations of current implementation. It worked,
but this is not guaranteed it will be accepted by bazaar community. I'm understand this too.

I just want to make it clear: I will not rewrite this code completely one more time.
If this approach is unacceptable then we should wait while somebody else will try
to do the better work.

> This seems to be the model suggested in 
> http://bazaar-vcs.org/VersionedProperties, and I think there should be 
> wider discussion before we abandon that idea in favor of something less 
> cohesive.
> 
> Perhaps you could rewrite the VersionedProperties spec and post it to 
> the list for discussion before presenting an implementation of an 
> unwritten version of the specification.

I want to clarify why I said "no".

In my first message I put copy of doc/developers/versioned-properties.txt
This document is already my version of that specification. Do you read it?

I started write this document in August 2007, but then I abandon my attempt,
because at that moment I receive suggestion from several reviewers that I was
not agreed with. Back in that days it was much closer to old VersionedProperties
spec. You still could find it in rejected pile in BundleBuggy. I reject it myself
after 3 iterations.

Today I have no time nor desire to implement ideal solution with new working tree
format and new repository format. As I wrote: versioned properties is not ends, but are
means for me. I want to have them because I know what I can build on top of them,
and this is not limited to eol support. But I'm not interested to polish them infinitely.

This means that if somebody want to return to old spec and start from it, then
just bb:reject my patch and do what you think is right.