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