-----BEGIN PGP SIGNED MESSAGE-----
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
>>> 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
>>> 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
> 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)
-----END PGP SIGNATURE-----
Received on 2011-10-10 17:24:58 CEST