Julian Foad <julianfoad_at_btopenworld.com> writes:
> When we get a property conflict, we store a message in "<filename>.prej"
> that says:
>
>> Trying to change property 'p' from 'v1' to 'v2',
>> but property has been locally changed from 'v1' to 'wcval'.
>
> That's OK for a short plain-text value, but is not human-readable for a
> very long value or a "binary" value, and not machine-parseable if the
> value contains a single-quote character.
>
> Mike and I agree it's totally obvious - "d'uh" - that we should store
> the "old" and "theirs" and "mine" values in a more rigorous,
> programmatically-accessible form, as we do for the file text in a file
> text conflict. This would enable tools built on top of Subversion to
> offer proper property conflict resolution.
>
> I see two solutions (Mike, I only thought of (1) until after talking to
> you last week, and then I realised you were probably thinking of (2)):
>
> (1) Save the item's "old", "theirs" and "mine" properties in the admin
> area if there is any property conflict on the item.
Why in the admin area? Why not in the working area?
> (2) For each property that conflicts, create "old", "theirs" and "mine"
> files holding the bare value of that property in the user's WC
> directory. (This is where we write the files for text conflicts.)
...ah, I see you were ahead of me :-). Yes, (2), and then there can
still be a human-readable .prej file to serve as a readme, explaining
what the other files are.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-15 01:14:29 CEST