[Peter Samuelson]
> If the "misspelled" property exists, probably the user already noticed
> the typo, that's why they're deleting it! I see no need for --force
> here.
>
> If the "misspelled" property does not exist, I think the warning that
> the property does not exist is just as good as a wa
Greg Stein wrote:
> Eh? So it already has a separate/different semantic?
No, it already had near-enough the same semantics: "allow property values that
this client thinks are invalid". This just extends it to mean "allow property
values *and names* that ...".
- Julian
> Yay.
> Bert Huijben
On 11/26/2012 06:38 PM, Peter Samuelson wrote:
>
> [Julian Foad]
>> In general, setting *or* deleting an unknown prop name causes nothing
>> significant to happen on *this* client, and may cause something
>> (expected or unexpected) to happen on another client.
>
> I don't get why we would want '
why I didn’t ask that specific question)
>
> Bert
>
> *From:* Greg Stein
> *Sent:* November 27, 2012 9:11 AM
> *To:* Julian Foad ,Branko Čibej
> *CC:* Subversion Development
> *Subject:* Re: [RFC] svn propset should require 'force' to set unknown
> svn:
Čibej
*CC:* Subversion Development
*Subject:* Re: [RFC] svn propset should require 'force' to set unknown svn:
propnames
Brane has done some excellent work here. But it seems nobody has asked
the question: why --force instead of (say) --allow-propname ?
Haven't we already decided
Brane has done some excellent work here. But it seems nobody has asked
the question: why --force instead of (say) --allow-propname ?
Haven't we already decided that --force is horribly overloaded, and
horribly undefined?
Thx,
-g
On Sun, Nov 18, 2012 at 9:50 PM, Julian Foad wrote:
> 'svn propset
Ben Reser wrote:
> On Mon, Nov 26, 2012 at 3:38 PM, Peter Samuelson wrote:
>> I don't get why we would want 'propdel --force' at all. Either the
>> "misspelled" property exists, or it doesn't.
>>
>> If the "misspelled" property exists, probably the user already
>> noticed the typo, that's why t
On Mon, Nov 26, 2012 at 3:38 PM, Peter Samuelson wrote:
> I don't get why we would want 'propdel --force' at all. Either the
> "misspelled" property exists, or it doesn't.
>
> If the "misspelled" property exists, probably the user already noticed
> the typo, that's why they're deleting it! I see
[Julian Foad]
> In general, setting *or* deleting an unknown prop name causes nothing
> significant to happen on *this* client, and may cause something
> (expected or unexpected) to happen on another client.
I don't get why we would want 'propdel --force' at all. Either the
"misspelled" property
On 26.11.2012 21:33, Julian Foad wrote:
> My conclusion is flagging 'propdel' is less important than flagging
> 'propset' but still useful, but not enough to make a fuss about.
> Oops, too late, I'va already made a fuss about it.
Heh. Actually, adding the check to propdel takes all of two lines o
Branko Čibej wrote:
> On 25.11.2012 23:30, Julian Foad wrote:
>> To answer the question I think you meant: requiring force for
>> setting svn:mergeinfo is a separate issue and shouldn't necessarily
>> work the same way or produce the same error message as the unknown
>> propname check. Personally,
On 25.11.2012 23:30, Julian Foad wrote:
> Branko Čibej wrote:
>
>> The latest change takes account of property name similarity. So for example,
>>
>> svn propset svn:foobar .
>>
>> will emit an error but will not suggest an alternative spelling, whereas
>>
>> svn propset svn:ignores .
>>
>>
Branko Čibej wrote:
> The latest change takes account of property name similarity. So for example,
>
> svn propset svn:foobar .
>
> will emit an error but will not suggest an alternative spelling, whereas
>
> svn propset svn:ignores .
>
> will suggest two, svn:ignore and svn:global-ign
The latest change takes account of property name similarity. So for example,
svn propset svn:foobar .
will emit an error but will not suggest an alternative spelling, whereas
svn propset svn:ignores .
will suggest two, svn:ignore and svn:global-ignores.
The only open question now, IMO,
On 24.11.2012 15:20, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, Nov 24, 2012 at 13:38:39 +0100:
>> On 24.11.2012 13:30, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Sat, Nov 24, 2012 at 12:33:01 +0100:
I'm also considering requiring --force if one tries to use a revision
property
Branko Čibej wrote on Sat, Nov 24, 2012 at 13:38:39 +0100:
> On 24.11.2012 13:30, Daniel Shahaf wrote:
> > Branko Čibej wrote on Sat, Nov 24, 2012 at 12:33:01 +0100:
> >> I'm also considering requiring --force if one tries to use a revision
> >> property name as a node property, and vice versa.
> >
On 24.11.2012 13:30, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, Nov 24, 2012 at 12:33:01 +0100:
>> I'm also considering requiring --force if one tries to use a revision
>> property name as a node property, and vice versa.
>>
> +0
>
>> $ svn ps svn:barfoo x .
>> svn: E195011: 'svn:barfoo' is
Branko Čibej wrote on Sat, Nov 24, 2012 at 12:33:01 +0100:
> I'm also considering requiring --force if one tries to use a revision
> property name as a node property, and vice versa.
>
+0
> $ svn ps svn:barfoo x .
> svn: E195011: 'svn:barfoo' is not a valid svn: property name; did you mean
> 's
On Fri, Nov 23, 2012 at 11:22:44AM -0800, Ben Reser wrote:
> On Fri, Nov 23, 2012 at 9:09 AM, Branko Čibej wrote:
> > No. The check specifically looks for a three-letter prefix ending in a
> > colon, and allows only one wrong character or transposition. It will
> > flag svm: but not tsvn:.
>
> sv
On 23.11.2012 18:09, Branko Čibej wrote:
> I agree that looking at the prefix is dicey, ...
... so I've tightened up the prefix matching so that --force is required
only when:
* the prefix is exactly 3 letters long (propname[3] == ':');
* and the first three letters differ in only one change
On Fri, Nov 23, 2012 at 9:09 AM, Branko Čibej wrote:
> No. The check specifically looks for a three-letter prefix ending in a
> colon, and allows only one wrong character or transposition. It will
> flag svm: but not tsvn:.
svk would pop up for anyone still using (no idea if anyone does) SVK.
>
On 23.11.2012 17:17, Mark Phippard wrote:
> Personally, I think checking for mis-spellings in "svn:" goes too far.
> For example, do these checks interfere with setting any of the tsvn:
> properties?
No. The check specifically looks for a three-letter prefix ending in a
colon, and allows only one
Branko Čibej wrote:
> On 23.11.2012 15:35, Julian Foad wrote:
>> In file included from subversion/libsvn_delta/compat.c:36:0:
>> ./subversion/svn_private_config.h:236:7:
> "SVN_QSORT_R_NORMAL_ARG_ORDER" is not defined
[...]
>
> Julian, we've had this discussion before. I'm not going to change
On Fri, Nov 23, 2012 at 5:43 AM, Branko Čibej wrote:
> On 19.11.2012 03:50, Julian Foad wrote:
>> Proposal:
>>
>> For any unrecognized property name in the 'svn:' name space, these would
>> bail out with an error unless '--force' is given:
>>
>> svn pset svn:foo
>> svn pedit svn:foo
>>
>> and
On 23.11.2012 16:31, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Nov 23, 2012 at 15:59:16 +0100:
>> On 23.11.2012 15:35, Julian Foad wrote:
>>> In file included from subversion/libsvn_delta/compat.c:36:0:
>>> ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is
>>> not
Daniel Shahaf wrote on Fri, Nov 23, 2012 at 17:31:05 +0200:
> Branko Čibej wrote on Fri, Nov 23, 2012 at 15:59:16 +0100:
> > On 23.11.2012 15:35, Julian Foad wrote:
> > > In file included from subversion/libsvn_delta/compat.c:36:0:
> > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_
Branko Čibej wrote on Fri, Nov 23, 2012 at 15:59:16 +0100:
> On 23.11.2012 15:35, Julian Foad wrote:
> > In file included from subversion/libsvn_delta/compat.c:36:0:
> > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is
> > not defined
> > --
> > In file included from subv
On 23.11.2012 15:35, Julian Foad wrote:
> In file included from subversion/libsvn_delta/compat.c:36:0:
> ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is
> not defined
> --
> In file included from subversion/libsvn_delta/svndiff.c:31:0:
> ./subversion/svn_private_config.h
In file included from subversion/libsvn_delta/compat.c:36:0:
./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is not
defined
--
In file included from subversion/libsvn_delta/svndiff.c:31:0:
./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is not
defin
On 23.11.2012 12:58, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Nov 23, 2012 at 11:43:29 +0100:
>> $ svn ps svm:ignore x .
>> svn: E195011: 'svm:ignore' is not a valid svn: property name; did you mean
>> 'svn:ignore'?
>> (Use --force if you're sure about 'svm:ignore'.)
>
> "To set the 'svm:
Branko Čibej wrote on Fri, Nov 23, 2012 at 11:43:29 +0100:
> On 19.11.2012 03:50, Julian Foad wrote:
> > Proposal:
> >
> > For any unrecognized property name in the 'svn:' name space, these would
> > bail out with an error unless '--force' is given:
> >
> > svn pset svn:foo
> > svn pedit svn:f
On 19.11.2012 03:50, Julian Foad wrote:
> Proposal:
>
> For any unrecognized property name in the 'svn:' name space, these would bail
> out with an error unless '--force' is given:
>
> svn pset svn:foo
> svn pedit svn:foo
>
> and all other subcommands where properties are handled would continu
On 11/19/2012 09:13 AM, Daniel Shahaf wrote:
> Another thing we could do is warn when unrecognised options are found in
> the config file (~/.subversion/*) or in the --config-option command-line
> option.
>
> This would be an independent improvement, i.e., it neither blocks nor
> is blocked by the
Julian Foad wrote on Mon, Nov 19, 2012 at 14:08:34 +:
> C. Michael Pilato wrote:
>
> > On 11/18/2012 10:56 PM, Daniel Shahaf wrote:
> >> Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
> >>> Thoughts, objections?
> >>
> >> Another related trap is setting a revprop as a nodeprop,
C. Michael Pilato wrote:
> On 11/18/2012 10:56 PM, Daniel Shahaf wrote:
>> Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
>>> Thoughts, objections?
>>
>> Another related trap is setting a revprop as a nodeprop, or vice-versa:
>> svn commit --with-revprop=svn:eol-style=native -m
On 11/18/2012 10:56 PM, Daniel Shahaf wrote:
> Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
>> Thoughts, objections?
>>
>
> Another related trap is setting a revprop as a nodeprop, or vice-versa:
> svn commit --with-revprop=svn:eol-style=native -mm foo.c
> svn propset svn:log
On Sun, Nov 18, 2012 at 9:50 PM, Julian Foad wrote:
> 'svn propset' lets us create any property name 'svn:foo', with good reason:
> we want old clients to be able to set and edit properties that only the newer
> clients know about. However, there is a pitfall for unwary users: it's east
> to m
Julian Foad wrote on Mon, Nov 19, 2012 at 02:50:46 +:
> Thoughts, objections?
>
Another related trap is setting a revprop as a nodeprop, or vice-versa:
svn commit --with-revprop=svn:eol-style=native -mm foo.c
svn propset svn:log x foo.c
You might want to require --force for these too
'svn propset' lets us create any property name 'svn:foo', with good reason: we
want old clients to be able to set and edit properties that only the newer
clients know about. However, there is a pitfall for unwary users: it's east to
mis-spell a prop name and not notice. For example:
svn:ign
39 matches
Mail list logo
