You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin Furter <mf...@rola.ch> on 2006/08/08 14:31:50 UTC

Bad property name

Hi All

I tried to edit a revision property and forgot to specify the property 
name, the current path was in a working copy:

> svn pe --revprop -r 13299 http://svn/svn

svn then started an editor with no content. After entering some text 
saving it and leaving the editor it showed the following message:

svn: Bad property name: 'http://svn/svn'

Ofcourse subversion is right and I didn't want to set that property. 
Instead I wanted to edit svn:log.

But I have two questions now:

1. Why does svn not complain if I try to edit a non-existing property?
My guess is that this is intentional so I can use an editor to create a 
new property.

2. Why does it not check the property name before starting the editor?

Client is svn, version 1.3.1 (r19032), server is 1.2.1 (r15230).

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Bad property name

Posted by Martin Furter <mf...@rola.ch>.
I added a partial patch and a logmessage to the issue, but it is untested.

If I find some time to setup a build and test environment I'll continue 
working on the patch but I can't promise anything.

Martin


On Tue, 8 Aug 2006, C. Michael Pilato wrote:

> C. Michael Pilato wrote:
>> C. Michael Pilato wrote:
>>
>>>> 2. Why does it not check the property name before starting the editor?
>>>
>>> Hrm.  Now there's a good question.  I'd call that a bug.
>>
>>
>> Aha.  The is-valid check happens down in libsvn_client, well after the
>> editor has been used to get a property value.  I think we should expose the
>> is_valid_propname (and similar) checks through the svn_client.h API, and
>> teach the command-line client to use them before firing up the editor.
>>
>> I'll file an ENHANCEMENT issue about this, Martin.
>
> Filed issue 2592.
>
> -- 
> C. Michael Pilato <cm...@collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Bad property name

Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> C. Michael Pilato wrote:
> 
>>>2. Why does it not check the property name before starting the editor?
>>
>>Hrm.  Now there's a good question.  I'd call that a bug.
> 
> 
> Aha.  The is-valid check happens down in libsvn_client, well after the
> editor has been used to get a property value.  I think we should expose the
> is_valid_propname (and similar) checks through the svn_client.h API, and
> teach the command-line client to use them before firing up the editor.
> 
> I'll file an ENHANCEMENT issue about this, Martin.

Filed issue 2592.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Bad property name

Posted by Daniel Rall <dl...@collab.net>.
On Tue, 08 Aug 2006, C. Michael Pilato wrote:

> David Glasser wrote:
> > On 8/8/06, C. Michael Pilato <cm...@collab.net> wrote:
> > 
> >> C. Michael Pilato wrote:
> >> >>2. Why does it not check the property name before starting the editor?
> >> >
> >> > Hrm.  Now there's a good question.  I'd call that a bug.
> >>
> >> Aha.  The is-valid check happens down in libsvn_client, well after the
> >> editor has been used to get a property value.  I think we should
> >> expose the
> >> is_valid_propname (and similar) checks through the svn_client.h API, and
> >> teach the command-line client to use them before firing up the editor.
> > 
> > 
> > Out of curiousity, is it intentional that propname validity checking
> > happens at the svn_client level and not at a lower level?
> > 
> > I was actually considering sending a message about a similar issue
> > just this week, after discovering a bug in svk where it misparsed the
> > auto-props configuration section and silently set properties with
> > names like " svn:eol-style" (with a leading space).  Having any "valid
> > property name" API at all would be great, but does it make sense to
> > allow weird property names at the repository level?  (I guess you have
> > to for compatibility reasons now.)
> 
> I'm pretty sure I've argued this (or something very similar regarding path
> names) *very* recently.  Sure, we could teach libsvn_repos to do similar
> checks (though, keep your grubby hands offa the libsvn_fs layer, bucko!).
> 
> Of course, doing this kind of check *only* at the repos layer instead of
> also at the client side is counterproductive.  Besides delaying sanity
> checks until well after real user work has been done, it also defeats one of
> the points of the checks in the first place -- to keep data that can't be
> transported via our XML protocol (ra-dav) off the wire entirely.

+1 on factoring the API into a libsvn_subr routine, and doing the
check early during a 'propedit' (rather than too late), and in the
appropriate libsvn_repos API.

Re: Bad property name

Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On 8/8/06, C. Michael Pilato <cm...@collab.net> wrote:
> 
>> C. Michael Pilato wrote:
>> >>2. Why does it not check the property name before starting the editor?
>> >
>> > Hrm.  Now there's a good question.  I'd call that a bug.
>>
>> Aha.  The is-valid check happens down in libsvn_client, well after the
>> editor has been used to get a property value.  I think we should
>> expose the
>> is_valid_propname (and similar) checks through the svn_client.h API, and
>> teach the command-line client to use them before firing up the editor.
> 
> 
> Out of curiousity, is it intentional that propname validity checking
> happens at the svn_client level and not at a lower level?
> 
> I was actually considering sending a message about a similar issue
> just this week, after discovering a bug in svk where it misparsed the
> auto-props configuration section and silently set properties with
> names like " svn:eol-style" (with a leading space).  Having any "valid
> property name" API at all would be great, but does it make sense to
> allow weird property names at the repository level?  (I guess you have
> to for compatibility reasons now.)

I'm pretty sure I've argued this (or something very similar regarding path
names) *very* recently.  Sure, we could teach libsvn_repos to do similar
checks (though, keep your grubby hands offa the libsvn_fs layer, bucko!).

Of course, doing this kind of check *only* at the repos layer instead of
also at the client side is counterproductive.  Besides delaying sanity
checks until well after real user work has been done, it also defeats one of
the points of the checks in the first place -- to keep data that can't be
transported via our XML protocol (ra-dav) off the wire entirely.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Bad property name

Posted by David Glasser <gl...@mit.edu>.
On 8/8/06, C. Michael Pilato <cm...@collab.net> wrote:
> C. Michael Pilato wrote:
> >>2. Why does it not check the property name before starting the editor?
> >
> > Hrm.  Now there's a good question.  I'd call that a bug.
>
> Aha.  The is-valid check happens down in libsvn_client, well after the
> editor has been used to get a property value.  I think we should expose the
> is_valid_propname (and similar) checks through the svn_client.h API, and
> teach the command-line client to use them before firing up the editor.

Out of curiousity, is it intentional that propname validity checking
happens at the svn_client level and not at a lower level?

I was actually considering sending a message about a similar issue
just this week, after discovering a bug in svk where it misparsed the
auto-props configuration section and silently set properties with
names like " svn:eol-style" (with a leading space).  Having any "valid
property name" API at all would be great, but does it make sense to
allow weird property names at the repository level?  (I guess you have
to for compatibility reasons now.)

--dave

-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Bad property name

Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
>>2. Why does it not check the property name before starting the editor?
> 
> Hrm.  Now there's a good question.  I'd call that a bug.

Aha.  The is-valid check happens down in libsvn_client, well after the
editor has been used to get a property value.  I think we should expose the
is_valid_propname (and similar) checks through the svn_client.h API, and
teach the command-line client to use them before firing up the editor.

I'll file an ENHANCEMENT issue about this, Martin.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Bad property name

Posted by "C. Michael Pilato" <cm...@collab.net>.
Martin Furter wrote:
> 
> Hi All
> 
> I tried to edit a revision property and forgot to specify the property
> name, the current path was in a working copy:
> 
>> svn pe --revprop -r 13299 http://svn/svn
> 
> 
> svn then started an editor with no content. After entering some text
> saving it and leaving the editor it showed the following message:
> 
> svn: Bad property name: 'http://svn/svn'
> 
> Ofcourse subversion is right and I didn't want to set that property.
> Instead I wanted to edit svn:log.
> 
> But I have two questions now:
> 
> 1. Why does svn not complain if I try to edit a non-existing property?
> My guess is that this is intentional so I can use an editor to create a
> new property.

Your guess is correct.

> 2. Why does it not check the property name before starting the editor?

Hrm.  Now there's a good question.  I'd call that a bug.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand