On 10/08/2011 05:20 PM, Branko Čibej wrote:
>
> On 06.10.2011 22:28, Neels J Hofmeyr wrote:
>> This table is / would be very useful if one tries to find all externals
>> defined or checked out in a given subtree, without having to first find and
>> then parse all externals skels.
>
>> But in fact it is little more than a cache for svn:externals props. It
>> duplicates information in a way. But it adds the knowledge of exactly which
>> repository and relpath an external is from (stores URLs in repos-root and
>> repos-relpath, readily parsed from the various formats found in
>> svn:externals definitions).
>
> 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'.
~Neels
Received on 2011-10-10 14:13:12 CEST