On 11.10.2011 10:01, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Oct 11, 2011 at 09:47:31 +0200:
>> On 11.10.2011 05:06, Konstantin Kolinko wrote:
>>> 2011/10/10 Branko Čibej <br...@apache.org>:
>>>>>> Answer's simple: never store the svn:externals property with the other
>>>>>> props, always parse it into and read it from the EXTERNALS table. After
>>>>>> all, it /is/ a magic property. This can be a completely wc-local
>>>>>> implementation-specific thing.
>>>>> ...and change the interface for managing externals, too?
>>>>>
>>>>> Currently we set externals by setting some multiline string (propset).
>>>>> When
>>>>> coming back later (propget/edit), we expect that string to be exactly
>>>>> identical to what was set earlier -- even if it contains my seven
>>>>> favourite
>>>>> quotes of Mark Twain. Parsing that value to a table immediately and
>>>> bringing
>>>>> it back later discards of Twain's quotes. Those aren't a use case, but
>>>>> line
>>>>> comments in svn:externals and various URL notations are ("^/foo" and
>>>>> "svn://example.com/repos/foo" currently amount to the exact same EXTERNALS
>>>>> row, i.e. same repos_id and def_repos_relpath).
>>>>>
>>>>> Ok, we could also store that plain string in the externals table instead
>>>>> of
>>>>> as a prop value. Does it really make a difference?
>>>>>
>>>>> Or we're talking about a complete feature change, not using the
>>>>> propset/propget API. Maybe something like
>>>>>
>>>>> svn external add --anchor="." --url="^/foo" --path="sub/dir/foo"
>>>>>
>>>>> Hmm, I think we better leave the prop as is, and have hooks that update
>>>>> the
>>>>> EXTERNALS table on every prop change (i.e. the way it is implemented right
>>>>> now, possible bugs aside).
>>>>> ...and try to find and somehow handle any abort conditions that might
>>>>> leave
>>>>> the EXTERNALS table out-of-sync. As a safety net include an EXTERNALS
>>>>> table
>>>>> check/update on 'svn cleanup'.
>>>> I don't really see that a propset to svn:externals, followed immediately
>>>> by a propget, should yield exactly the same content, as long as it's
>>>> semantically identical. In other words, it'd be quite OK to treat such a
>>>> propset differently from other propsets, i.e., to parse whatever was set
>>>> into the EXTERNALS table, and have the propget read from there. It's not
>>>> as if we ever promised that magic properties are anything but magic. :)
>>> EXTERNALS table is in wc only, but propget can be called on repository URL.
>>>
>>> I think it would be a mess if results of calling propget on URL and on
>>> WC do not match.
>> The repository would only see pre-parsed svn:externals, so the results
>> would (eventually) match. As to it being a mess, I don't understand why.
>> After all, the idea is for the result to be semantially identical.
>> Besides, nobody complains about, e.g., svn:executable, where we already
>> munge the value.
>>
> svn:executable is binary, and we've munged it since pre-1.0. If we
> start now deleting comments in svn:externals, we'd (a) be implementing
> a data-loss feature ("Subversion silently deleted my Mark Twain quotes
> from my svn:externals property"), (b) removing the option to include
> comments in property values.
>
Hmm, I just caught myself discussing changes to svn:externals that
didn't involve removing the whole horrible feature. Must remember to be
more careful. :)
-- Brane
