2011/10/10 Branko Čibej <brane_at_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.
Best regards,
Konstantin Kolinko
Received on 2011-10-11 05:07:13 CEST