On 06/20/2013 07:01 PM, Julian Foad wrote:
> Arwin Arni wrote:
>> Properties are validated regardless of the action on the property. This poses a
>> problem when it comes to very old repositories that contain "invalid"
>> properties committed by very old clients that didn't perform these
>> validations.
> What cases are you talking about, specifically?
Iam talking about svn:entry:committed-date. I came across a repository
with this non-regular property set on a bunch of revisions. The current
code disallows the addition (and deletion) of such properties, so
figuring out when/how that property got there in the first place is
something I'm yet to look into. I'm guessing it was a very old
libsvn_repos that allowed this.
> Invalid prop names that are rejected by 'svn ps' are not rejected by 'svn propdel':
>
> [[[
> $ svn ps svn:foo v .
> svn: E195011: 'svn:foo' is not a valid svn: property name; re-run with '--force' to set it
> $ svn ps svn:foo v . --force
> property 'svn:foo' set on '.'
> $ svn pd svn:foo .
> property 'svn:foo' deleted from '.'.
> ]]]
>
> Invalid prop values that are rejected by 'svn ps' are not rejected by 'svn propdel':
>
> [[[
> $ svn ps svn:externals foo-bar .
> svn: E195005: Error parsing svn:externals property on 'wc': 'foo-bar'
> $ svn ps svn:externals foo-bar . --force
> svn: E195005: Error parsing svn:externals property on 'wc': 'foo-bar'
> $ svn pl -v
> [...nothing shown...]
>
> [...edit the repository by hand to create an invalid prop value...]
>
> $ svn pl -vR
> Properties on '.':
> svn:externals
> foo-bar
> $ svn pd svn:externals .
> property 'svn:externals' deleted from '.'.
> ]]]
>
> at least for the cases I tried, using an svn 1.8.0 release candidate.
>
>> My contention is that we need to check the validity of the property
>> only during addition and modification. Validation during deletion prevents the
>> user from removing what he recognizes as an invalid property.
> Agreed. We discussed this before, at least in terms of the command-line client, and that was the conclusion we agreed on. The principle should apply consistently, so +1 to fix any APIs or wherever you're seeing the problem, to do the same.
>
> - Julian
Received on 2013-06-21 08:41:30 CEST