Branko Čibej wrote on Tue, Oct 11, 2011 at 09:47:31 +0200:
> 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.
>
svn:executable is binary, and we've munged it since pre-1.0. If we
start now deleting comments in svn:externals, we'd (a) be implementing
a data-loss feature ("Subversion silently deleted my Mark Twain quotes
from my svn:externals property"), (b) removing the option to include
comments in property values.
> -- Brane
>
