-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 10.10.2011 14:12, Neels J Hofmeyr wrote:
> 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'.
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. :)
- -- Brane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
iQEcBAEBCgAGBQJOkw4gAAoJECm4ktDIYoUBeoYH/3fxcP+/s8njPi0VKBoP6JSG
m9zPGChadAnTSB6JzG62WUfHHFKSo/t96acVFScGv0bwPG9fairHrUpgJUD2MfTQ
P9MR45AHQ9lQSmPrkdt8YY7IsAG+6hPEm9kXdXWyXa6R86QjJrZtrrz0JZKTJF9N
hnQVCF6TRHrzUIPCETiTWIBvkS2x1bOtal+t3hY80ZqZyds8KG5jqz4VDqIQm5by
I7BpQI/VM+1bU7s8GL3svt/uYrbUvEJgBU45ZgyWxdMA21b8RIiA1LmJfwrFboH3
174fK/kT2wRAsdHeQ0HX1Z5Np59vducp1jHdLp8sB1wFL4JEW+abN3xw7lWFFMs=
=whcQ
-----END PGP SIGNATURE-----
Received on 2011-10-10 17:24:58 CEST