Re: svn commit: r1412554 - in /subversion/trunk/subversion: include/private/svn_string_private.h libsvn_subr/string.c tests/libsvn_subr/string-test.c
On 22.11.2012 17:22, Julian Foad wrote:
>> Author: brane
>> Date: Thu Nov 22 14:00:48 2012
>> New Revision: 1412554
>> Modified: subversion/trunk/subversion/libsvn_subr/string.c
>> svn_cstring__similarity(const char *stra, const char *strb,
>> svn_membuf_t *buffer, apr_size_t *rlcs)
>> {
>> - const apr_size_t lena = strlen(stra);
>> - const apr_size_t lenb = strlen(strb);
>> + const svn_string_t stringa = {stra, strlen(stra)};
>> + const svn_string_t stringb = {strb, strlen(strb)};
> Unfortunately our C'89 coding standard doesn't allow us to use non-constant
> initializers, and there are some compilers occasionally used to build
> Subversion that don't accept it.
Heh, by the way:
subversion/libsvn_fs_fs/fs_fs.c: In function 'get_cached_node_revision_body':
subversion/libsvn_fs_fs/fs_fs.c:2241: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:2242: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c: In function 'set_cached_node_revision_body':
subversion/libsvn_fs_fs/fs_fs.c:2268: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:2269: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c: In function 'parse_revprop':
subversion/libsvn_fs_fs/fs_fs.c:3532: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:3532: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c: In function 'get_revision_proplist':
subversion/libsvn_fs_fs/fs_fs.c:3834: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c: In function 'read_representation':
subversion/libsvn_fs_fs/fs_fs.c:5186: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:5186: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c: In function
'svn_fs_fs__try_process_file_contents':
subversion/libsvn_fs_fs/fs_fs.c:5358: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:5358: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:5363: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:5363: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c: In function 'svn_fs_fs__get_proplist':
subversion/libsvn_fs_fs/fs_fs.c:5662: warning: initializer element is not
computable at load time
subversion/libsvn_fs_fs/fs_fs.c:5662: warning: initializer element is not
computable at load time
subversion/libsvn_repos/reporter.c: In function 'delta_files':
subversion/libsvn_repos/reporter.c:721: warning: initializer element is not
computable at load time
subversion/libsvn_repos/reporter.c:722: warning: initializer element is not
computable at load time
subversion/libsvn_repos/reporter.c:723: warning: initializer element is not
computable at load time
tools/server-side/fsfs-reorg.c: In function 'update_text':
tools/server-side/fsfs-reorg.c:2472: warning: initializer element is not
computable at load time
tools/client-side/svn-bench/null-log-cmd.c: In function 'svn_cl__null_log':
tools/client-side/svn-bench/null-log-cmd.c:137: warning: initializer element is
not computable at load time
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 continue to work > as normal, no '--force' needed Here's what the prototype currently does. Any suggestions for better wording are most welcome. $ 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'.) $ svn ps gvm:ignore x . property 'gvm:ignore' set on '.' $ svn ps gvn:ignore x . svn: E195011: 'gvn:ignore' is not a valid svn: property name; did you mean 'svn:ignore'? (Use --force if you're sure about 'gvn:ignore'.) $ svn ps svn:ignores x . svn: E195011: 'svn:ignores' is not a valid svn: property name; did you mean 'svn:ignore'? (Use --force if you're sure about 'svn:ignores'.) $ svn ps svn:local-ignore x . svn: E195011: 'svn:local-ignore' is not a valid svn: property name; did you mean 'svn:global-ignores'? (Use --force if you're sure about 'svn:local-ignore'.) -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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:foo
> >
> > and all other subcommands where properties are handled would continue to
> > work as normal, no '--force' needed
>
> Here's what the prototype currently does. Any suggestions for better
> wording are most welcome.
Nice work :-)
> $ 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:ignore' property, re-run with '--force'."
Two differences: (a) drop the "if you're sure" wording in favour of "to
do X", (b) single quotes around the --option.
---
For reference:
main.c- _("Lock comment file is a versioned file; "
main.c: "use '--force-log' to override"));
--
main.c- _("The log message is a pathname "
main.c: "(was -F intended?); use '--force-log' to
override"));
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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:ignore' property, re-run with '--force'." > > Two differences: (a) drop the "if you're sure" wording in favour of "to > do X", (b) single quotes around the --option. Thanks, I'll amend the message. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 defined -- In file included from subversion/libsvn_subr/auth.c:34:0: ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is not defined -- In file included from subversion/libsvn_subr/cache-inprocess.c:30:0: ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is not defined -- In file included from subversion/libsvn_subr/cache-membuffer.c:31:0: ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is not defined -- [...] (The relevant line number looks like 235 in my editor not 236.) - Julian
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > not defined > -- > In file included from subversion/libsvn_subr/auth.c:34:0: > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > not defined > -- > In file included from subversion/libsvn_subr/cache-inprocess.c:30:0: > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > not defined > -- > In file included from subversion/libsvn_subr/cache-membuffer.c:31:0: > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > not defined > -- > [...] > > (The relevant line number looks like 235 in my editor not 236.) Julian, we've had this discussion before. I'm not going to change the accepted way of checking autoconf macros just because you insist on turning on warnings about perfectly valid and 15-years standard behaviour of the C preprocessor. That by the way is not even turned on in maintainer-mode. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
problems committing with serf
Hi, using the latest build from 1.7.x with serf configured. I'm trying to commit changes to a working copy to a Google code repository, this fails with: Sending. svn: E175002: Commit failed (details follow): svn: E175002: MKACTIVITY request on '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f 7297de5' failed: 405 Method Not Allowed svn: E175002: DELETE request on '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f7297 de5' failed: 405 Method Not Allowed I had this before but didn't report it due to deadlines. Back then switching to neon solved the problem. But now that serf is destined to be the only DAV lib in 1.8 I think it's worth checking this out further. I haven't committed the change yet, and the working copy is available here: https://skydrive.live.com/redir?resid=D000F60A347E5B37!11029 If someone wants to analyze the problem (I'm not familiar with serf at all), just send me a note with your google account and I'll grant you commit access - which I think is required to reproduce the problem. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/>The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: svn commit: r1412554 - in /subversion/trunk/subversion: include/private/svn_string_private.h libsvn_subr/string.c tests/libsvn_subr/string-test.c
Branko Čibej wrote: > On 22.11.2012 17:22, Julian Foad wrote: >> Unfortunately our C'89 coding standard doesn't allow us to use >> non-constant initializers, and there are some compilers occasionally >> used to build Subversion that don't accept it. > > Heh, by the way: > > subversion/libsvn_fs_fs/fs_fs.c:2241: warning: initializer element is not > computable at load time [...] > tools/client-side/svn-bench/null-log-cmd.c:137: warning: initializer element > is > not computable at load time All fixed in r1412911. (I did a clean(ish) build with '-pedantic' to confirm.) Thanks. - Julian
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 subversion/libsvn_delta/svndiff.c:31:0: > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > > not defined > > -- > > In file included from subversion/libsvn_subr/auth.c:34:0: > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > > not defined > > -- > > In file included from subversion/libsvn_subr/cache-inprocess.c:30:0: > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > > not defined > > -- > > In file included from subversion/libsvn_subr/cache-membuffer.c:31:0: > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is > > not defined > > -- > > [...] > > > > (The relevant line number looks like 235 in my editor not 236.) > > Julian, we've had this discussion before. I'm not going to change the > accepted way of checking autoconf macros just because you insist on > turning on warnings about perfectly valid and 15-years standard > behaviour of the C preprocessor. That by the way is not even turned on > in maintainer-mode. The warning is useful to catch spelling errors in macros (example: '#if APR_HAS_IPv6'). +1 to changing the code to always define SVN_QSORT_R_NORMAL_ARG_ORDER, as either 0 or 1. I see no downside to that, do you?
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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_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 defined > > > -- > > > In file included from subversion/libsvn_subr/auth.c:34:0: > > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" > > > is not defined > > > -- > > > In file included from subversion/libsvn_subr/cache-inprocess.c:30:0: > > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" > > > is not defined > > > -- > > > In file included from subversion/libsvn_subr/cache-membuffer.c:31:0: > > > ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" > > > is not defined > > > -- > > > [...] > > > > > > (The relevant line number looks like 235 in my editor not 236.) > > > > Julian, we've had this discussion before. I'm not going to change the > > accepted way of checking autoconf macros just because you insist on > > turning on warnings about perfectly valid and 15-years standard > > behaviour of the C preprocessor. That by the way is not even turned on > > in maintainer-mode. > > The warning is useful to catch spelling errors in macros (example: '#if > APR_HAS_IPv6'). > > +1 to changing the code to always define SVN_QSORT_R_NORMAL_ARG_ORDER, > as either 0 or 1. I see no downside to that, do you? Put another way: saying that '#if UNDEFINED_MACRO' is well-defined just says the code is correct. Hence, changing the code to avoid that construct is about robustness, or clarity, rahter than correctness.
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 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 defined >>> -- >>> In file included from subversion/libsvn_subr/auth.c:34:0: >>> ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is >>> not defined >>> -- >>> In file included from subversion/libsvn_subr/cache-inprocess.c:30:0: >>> ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is >>> not defined >>> -- >>> In file included from subversion/libsvn_subr/cache-membuffer.c:31:0: >>> ./subversion/svn_private_config.h:236:7: "SVN_QSORT_R_NORMAL_ARG_ORDER" is >>> not defined >>> -- >>> [...] >>> >>> (The relevant line number looks like 235 in my editor not 236.) >> Julian, we've had this discussion before. I'm not going to change the >> accepted way of checking autoconf macros just because you insist on >> turning on warnings about perfectly valid and 15-years standard >> behaviour of the C preprocessor. That by the way is not even turned on >> in maintainer-mode. > The warning is useful to catch spelling errors in macros (example: '#if > APR_HAS_IPv6'). > > +1 to changing the code to always define SVN_QSORT_R_NORMAL_ARG_ORDER, > as either 0 or 1. I see no downside to that, do you? Are we going to change every instance of using #if in the code to check autoconf macros? If yes, please update hacking.html first. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
RE: svn commit: r1412911 - in /subversion/trunk: subversion/libsvn_fs_fs/fs_fs.c subversion/libsvn_repos/reporter.c tools/client-side/svn-bench/null-log-cmd.c tools/server-side/fsfs-reorg.c
I can easily make these cases a compile error with Visual C++, but that will probably make other developers call it a broken/old/(fill in your own curse word) compiler for following such an old standard. Suggestions? Bert *From:* julianf...@apache.org *Sent:* November 23, 2012 4:19 PM *To:* comm...@subversion.apache.org *Subject:* svn commit: r1412911 - in /subversion/trunk: subversion/libsvn_fs_fs/fs_fs.c subversion/libsvn_repos/reporter.c tools/client-side/svn-bench/null-log-cmd.c tools/server-side/fsfs-reorg.c Author: julianfoad Date: Fri Nov 23 15:18:48 2012 New Revision: 1412911 URL: http://svn.apache.org/viewvc?rev=1412911&view=rev Log: Do not use non-constant initializers in struct variables, since this violates our C'89 coding standard. Although most compilers used for Subversion support non-constant initializers, some do not, such as Solaris SunPRO. Note that GCC requires the '-pedantic' option to report this. A previous commit of this kind was r1352068.
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 all other subcommands where properties are handled would continue to >> work as normal, no '--force' needed > > Here's what the prototype currently does. Any suggestions for better > wording are most welcome. > > $ 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'.) > > $ svn ps gvm:ignore x . > property 'gvm:ignore' set on '.' > > $ svn ps gvn:ignore x . > svn: E195011: 'gvn:ignore' is not a valid svn: property name; did you mean > 'svn:ignore'? > (Use --force if you're sure about 'gvn:ignore'.) > > $ svn ps svn:ignores x . > svn: E195011: 'svn:ignores' is not a valid svn: property name; did you mean > 'svn:ignore'? > (Use --force if you're sure about 'svn:ignores'.) > > $ svn ps svn:local-ignore x . > svn: E195011: 'svn:local-ignore' is not a valid svn: property name; did you > mean 'svn:global-ignores'? > (Use --force if you're sure about 'svn:local-ignore'.) 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? I would be very much against that as they are widely used. Your example shows blocking gvn:ignore. AFAIK, the gvn project is not being used since Google decided not to use SVN, but what if they had? Would we really want to require --force for properties named gvn:*? http://code.google.com/p/gvn/ It is difficult to say because I can see the value in what you are doing here. It just seems like it is walking us down a path that we typically try to stay away from. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: problems committing with serf
Stefan Küng writes: > Sending. > svn: E175002: Commit failed (details follow): > svn: E175002: MKACTIVITY request on > '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f > 7297de5' failed: 405 Method Not Allowed > svn: E175002: DELETE request on > '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f7297 > de5' failed: 405 Method Not Allowed > > > I had this before but didn't report it due to deadlines. Back then switching > to neon solved the problem. > But now that serf is destined to be the only DAV lib in 1.8 I think it's > worth checking this out further. > > I haven't committed the change yet, and the working copy is available here: > https://skydrive.live.com/redir?resid=D000F60A347E5B37!11029 > That's an http:// working copy. Does googlecode allow commits over http? Does the commit work if you relocate to https? -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 the > accepted way of checking autoconf macros just because you insist on > turning on warnings about perfectly valid and 15-years standard > behaviour of the C preprocessor. That by the way is not even turned on > in maintainer-mode. You clearly feel very strongly about that. Fine. I'm removing "-Wundef" from my local compiler flags now. I don't "insist" on using that warning; rather I found it useful: in conjunction with a consistent *convention* of testing with "#ifdef" it has occasionally helped me catch bugs in the past. Yet it is no silver bullet: the opposite kind of bugs can happen too. I'm fully aware the usage is "perfectly valid" C, but that and being however many years old doesn't by itself mean it's a good idea, of course. On the other hand, I do believe consistency is important. Presently Subversion code is self-consistent in using "#ifdef", apart from this one instance, while inconsistent with some (many?) other autoconf users, including APR, which use "#if". If we still value consistency in this project, we should consider switching all our usage to "#if". I'm not volunteering to do that. And I only said "consider" -- I'm not insisting and I don't wish to prolong this discussion. Ugh, I hate conflict. Can we talk about some exciting technical design issue next please :-) - Julian
Re: problems committing with serf
On 23.11.2012 17:20, Philip Martin wrote: Stefan Küng writes: Sending. svn: E175002: Commit failed (details follow): svn: E175002: MKACTIVITY request on '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f 7297de5' failed: 405 Method Not Allowed svn: E175002: DELETE request on '/svn/!svn/act/4b7f5c8e-5e27-f145-929b-dfe9f7297 de5' failed: 405 Method Not Allowed I had this before but didn't report it due to deadlines. Back then switching to neon solved the problem. But now that serf is destined to be the only DAV lib in 1.8 I think it's worth checking this out further. I haven't committed the change yet, and the working copy is available here: https://skydrive.live.com/redir?resid=D000F60A347E5B37!11029 That's an http:// working copy. Does googlecode allow commits over http? Does the commit work if you relocate to https? Argh! Yes of course. Used the wrong working copy here. I assumed it was the same problem I had before where it worked with neon, but this time even neon wouldn't work (haven't tried that before since I didn't wanted to mess with the situation). Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/>The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net
Re: svn commit: r1412911 - in /subversion/trunk: subversion/libsvn_fs_fs/fs_fs.c subversion/libsvn_repos/reporter.c tools/client-side/svn-bench/null-log-cmd.c tools/server-side/fsfs-reorg.c
Bert Huijben wrote: > I can easily make these cases a compile error with Visual C++, > but that will probably make other developers call it a broken/ > old/(fill in your own curse word) compiler for following such > an old standard. > > Suggestions? Honestly, I would like to suggest that we find out whether Subversion packagers who have complained about their compiler not supporting this construct have an acceptable alternative. And then, if they do, I would like to add this constuct to a list of exceptions to C'89 that we allow in our code, and then use it, because it significantly improves code readability. We already have other exceptions to strict C'89 compliance, which nobody has complained about. Here's a couple of examples reported by "gcc -pedantic": subversion/libsvn_subr/cmdline.c:621:26: ISO C forbids passing argument 3 of 'svn_auth_set_parameter' between function pointer and 'void *' subversion/libsvn_subr/win32_crashrpt.c:1:0: ISO C forbids an empty translation unit - Julian > URL: http://svn.apache.org/viewvc?rev=1412911&view=rev > Log: > Do not use non-constant initializers in struct variables, since this > violates our C'89 coding standard. Although most compilers used for > Subversion support non-constant initializers, some do not, such as Solaris > SunPRO. Note that GCC requires the '-pedantic' option to report this. > > A previous commit of this kind was r1352068.
Re: svn commit: r1412911 - in /subversion/trunk: subversion/libsvn_fs_fs/fs_fs.c subversion/libsvn_repos/reporter.c tools/client-side/svn-bench/null-log-cmd.c tools/server-side/fsfs-reorg.c
Julian Foad writes: > subversion/libsvn_subr/cmdline.c:621:26: ISO C forbids passing argument 3 of > 'svn_auth_set_parameter' between function pointer and 'void *' ISO C allows function pointers and void * to be a different sizes but POSIX's dlsym(3) more-or-less guarantees they are the same size. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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 wrong character or transposition. It will flag svm: but not tsvn:. > I would be very much against that as they are widely > used. Your example shows blocking gvn:ignore. AFAIK, the gvn project > is not being used since Google decided not to use SVN, but what if > they had? Would we really want to require --force for properties > named gvn:*? Yes. > http://code.google.com/p/gvn/ > > It is difficult to say because I can see the value in what you are > doing here. It just seems like it is walking us down a path that we > typically try to stay away from. The intent of the proposed change is to warn people about misspelling svn: properties. Surely the prefix can be misspelt as well? Why should svm:needs-lock be silently accepted, but not svn:global-ignore? I agree that looking at the prefix is dicey, which is why I defined the constraints as explained above. I'm also looking at options for not flagging non-svn: properties that are different enough from the known ones; for example, these would be flagged: svm:needs-lock svn:global-ignore gvn:ignore but not gvn:defrobify gvn:local-ignores I know how to do this, but I'm not clear yet about how or where to draw the line. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
svnmucc: trivial spelling error in help message
The text: --config-option ARG use ARG so override a configuration option\ should presumably be: --config-option ARG use ARG to override a configuration option\ i.e. change "so" to "to".
Re: svnmucc: trivial spelling error in help message
sebb wrote: > The text: > > --config-option ARG use ARG so override a configuration option\ > > should presumably be: > > --config-option ARG use ARG to override a configuration option\ > > i.e. change "so" to "to". I'm on trivia duty today. Thanks! Fixed on trunk in r1413033. - Julian
Re: svn commit: r1411629 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
This test isn't cleaning up after itself (or before a subsequent run). The
first time I run it in a working copy, it passes, but the next time, I get
the following error:
$ ./fs-test 37
subversion/tests/libsvn_fs/fs-test.c:4908: (apr_err=160033)
subversion/tests/svn_test_fs.c:183: (apr_err=160033)
subversion/tests/svn_test_fs.c:121: (apr_err=160033)
svn_tests: E160033: cannot create fs 'test-delete-fs' there is already a
directory of that name
subversion/libsvn_fs/fs-loader.c:515: (apr_err=160033)
subversion/libsvn_fs/fs-loader.c:322: (apr_err=160033)
subversion/libsvn_fs/fs-loader.c:162: (apr_err=160033)
svn_tests: E160033: Failed to load module for FS type 'bdb'
FAIL: fs-test 37: test svn_fs_delete_fs
I suspect there's some boilerplate somewhere that was left out.
-Hyrum
On Tue, Nov 20, 2012 at 6:52 AM, wrote:
> Author: philip
> Date: Tue Nov 20 11:52:56 2012
> New Revision: 1411629
>
> URL: http://svn.apache.org/viewvc?rev=1411629&view=rev
> Log:
> Explicitly test svn_fs_delete_fs.
>
> * subversion/tests/libsvn_fs/fs-test.c
> (delete_fs): New test.
> (test_list): Add new test.
>
> Modified:
> subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
>
> Modified: subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/libsvn_fs/fs-test.c?rev=1411629&r1=1411628&r2=1411629&view=diff
>
> ==
> --- subversion/trunk/subversion/tests/libsvn_fs/fs-test.c (original)
> +++ subversion/trunk/subversion/tests/libsvn_fs/fs-test.c Tue Nov 20
> 11:52:56 2012
> @@ -4896,6 +4896,26 @@ node_history(const svn_test_opts_t *opts
>return SVN_NO_ERROR;
> }
>
> +/* Test svn_fs_delete_fs(). */
> +static svn_error_t *
> +delete_fs(const svn_test_opts_t *opts,
> + apr_pool_t *pool)
> +{
> + svn_fs_t *fs;
> + const char *path;
> + svn_node_kind_t kind;
> +
> + SVN_ERR(svn_test__create_fs(&fs, "test-delete-fs", opts, pool));
> + path = svn_fs_path(fs, pool);
> + SVN_ERR(svn_io_check_path(path, &kind, pool));
> + SVN_TEST_ASSERT(kind != svn_node_none);
> + SVN_ERR(svn_fs_delete_fs(path, pool));
> + SVN_ERR(svn_io_check_path(path, &kind, pool));
> + SVN_TEST_ASSERT(kind == svn_node_none);
> +
> + return SVN_NO_ERROR;
> +}
> +
>
>
> /*
> */
> @@ -4979,5 +4999,7 @@ struct svn_test_descriptor_t test_funcs[
> "create and modify small file"),
> SVN_TEST_OPTS_PASS(node_history,
> "test svn_fs_node_history"),
> +SVN_TEST_OPTS_PASS(delete_fs,
> + "test svn_fs_delete_fs"),
> SVN_TEST_NULL
>};
>
>
>
Re: [RFC] svn propset should require 'force' to set unknown svn: propnames
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. > I agree that looking at the prefix is dicey, which is why I defined the > constraints as explained above. I'm also looking at options for not > flagging non-svn: properties that are different enough from the known > ones; for example, these would be flagged: > > svm:needs-lock > svn:global-ignore > gvn:ignore > > but not > > gvn:defrobify > gvn:local-ignores > > > I know how to do this, but I'm not clear yet about how or where to draw > the line. Difficult decision here. On one hand we have something that's probably going to help make a lot of peoples lives easier but it might make a small minority's life harder. I'm inclined to agree with Mark here that we shouldn't match on prefixes. However, on the other hand, aren't most of these property names likely only to being set by programs using our library and not the command line client. As such they wouldn't be prone to this code since Brane's changes are only in the command line client. In the svk example I gave above, svk:merge is not really intended to be modified by hand. gvn might be the only exception to that which we've mentioned, I'm not super familiar with it. Looking at the page it says it uses the svn client for most operations and the python bindings for others. It's also worth nothing that I think both gvn and svk are mostly unused at this point. Are there other common examples out there that would trip this?
Re: svn commit: r1411629 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
I did a little poking and fixed this in r1413046.
On Fri, Nov 23, 2012 at 2:18 PM, Hyrum K Wright wrote:
> This test isn't cleaning up after itself (or before a subsequent run).
> The first time I run it in a working copy, it passes, but the next time, I
> get the following error:
>
> $ ./fs-test 37
> subversion/tests/libsvn_fs/fs-test.c:4908: (apr_err=160033)
> subversion/tests/svn_test_fs.c:183: (apr_err=160033)
> subversion/tests/svn_test_fs.c:121: (apr_err=160033)
> svn_tests: E160033: cannot create fs 'test-delete-fs' there is already a
> directory of that name
> subversion/libsvn_fs/fs-loader.c:515: (apr_err=160033)
> subversion/libsvn_fs/fs-loader.c:322: (apr_err=160033)
> subversion/libsvn_fs/fs-loader.c:162: (apr_err=160033)
> svn_tests: E160033: Failed to load module for FS type 'bdb'
> FAIL: fs-test 37: test svn_fs_delete_fs
>
> I suspect there's some boilerplate somewhere that was left out.
>
> -Hyrum
>
>
> On Tue, Nov 20, 2012 at 6:52 AM, wrote:
>
>> Author: philip
>> Date: Tue Nov 20 11:52:56 2012
>> New Revision: 1411629
>>
>> URL: http://svn.apache.org/viewvc?rev=1411629&view=rev
>> Log:
>> Explicitly test svn_fs_delete_fs.
>>
>> * subversion/tests/libsvn_fs/fs-test.c
>> (delete_fs): New test.
>> (test_list): Add new test.
>>
>> Modified:
>> subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
>>
>> Modified: subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
>> URL:
>> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/libsvn_fs/fs-test.c?rev=1411629&r1=1411628&r2=1411629&view=diff
>>
>> ==
>> --- subversion/trunk/subversion/tests/libsvn_fs/fs-test.c (original)
>> +++ subversion/trunk/subversion/tests/libsvn_fs/fs-test.c Tue Nov 20
>> 11:52:56 2012
>> @@ -4896,6 +4896,26 @@ node_history(const svn_test_opts_t *opts
>>return SVN_NO_ERROR;
>> }
>>
>> +/* Test svn_fs_delete_fs(). */
>> +static svn_error_t *
>> +delete_fs(const svn_test_opts_t *opts,
>> + apr_pool_t *pool)
>> +{
>> + svn_fs_t *fs;
>> + const char *path;
>> + svn_node_kind_t kind;
>> +
>> + SVN_ERR(svn_test__create_fs(&fs, "test-delete-fs", opts, pool));
>> + path = svn_fs_path(fs, pool);
>> + SVN_ERR(svn_io_check_path(path, &kind, pool));
>> + SVN_TEST_ASSERT(kind != svn_node_none);
>> + SVN_ERR(svn_fs_delete_fs(path, pool));
>> + SVN_ERR(svn_io_check_path(path, &kind, pool));
>> + SVN_TEST_ASSERT(kind == svn_node_none);
>> +
>> + return SVN_NO_ERROR;
>> +}
>> +
>>
>>
>> /*
>> */
>> @@ -4979,5 +4999,7 @@ struct svn_test_descriptor_t test_funcs[
>> "create and modify small file"),
>> SVN_TEST_OPTS_PASS(node_history,
>> "test svn_fs_node_history"),
>> +SVN_TEST_OPTS_PASS(delete_fs,
>> + "test svn_fs_delete_fs"),
>> SVN_TEST_NULL
>>};
>>
>>
>>
>
Re: svn commit: r1413109 - in /subversion/trunk: ./ subversion/svnrdump/svnrdump.c subversion/svnrdump/svnrdump.h
On 24.11.2012 01:39, hwri...@apache.org wrote: > Author: hwright > Date: Sat Nov 24 00:39:38 2012 > New Revision: 1413109 > > URL: http://svn.apache.org/viewvc?rev=1413109&view=rev > Log: > Cherrypick r1413107 from the ev2-export branch. I'm going to be brave here > and develop on trunk. The plan is to implement the Ev2 editor in parallel > with the existing implementation, which should negatively impact 1.8 > releasability. I'm going to assume you meant "should *not*" in that last line. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1413015 - in /subversion/trunk/subversion: svn/propedit-cmd.c svn/propset-cmd.c tests/cmdline/prop_tests.py tests/cmdline/stat_tests.py tests/cmdline/svntest/actions.py
br...@apache.org wrote on Fri, Nov 23, 2012 at 18:24:42 -:
> Author: brane
> Date: Fri Nov 23 18:24:40 2012
> New Revision: 1413015
>
> URL: http://svn.apache.org/viewvc?rev=1413015&view=rev
> Log:
> Fix issue #4261 (require --force to set unknown svn: prop names).
>
> +def almost_known_prop_names(sbox):
> + "propset with svn: prefix but unknown name"
> +
> + sbox.build()
Pass read_only=True ?
> + wc_dir = sbox.wc_dir
> + iota_path = sbox.ospath('iota')
> +
> + # Node properties
> + svntest.actions.set_prop('svn:exemutable', 'x', iota_path,
> + "svn: E195011: 'svn:exemutable' "
> + "is not a valid svn: property name")
> + svntest.actions.set_prop('svn:exemutable', 'x', iota_path, force=True)
> + svntest.actions.set_prop('tsvn:exemutable', 'x', iota_path)
Re: svn commit: r1411629 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
Revert r1412515 then?
Hyrum K Wright wrote on Fri, Nov 23, 2012 at 15:29:32 -0500:
> I did a little poking and fixed this in r1413046.
>
>
> On Fri, Nov 23, 2012 at 2:18 PM, Hyrum K Wright wrote:
>
> > This test isn't cleaning up after itself (or before a subsequent run).
> > The first time I run it in a working copy, it passes, but the next time, I
> > get the following error:
> >
> > $ ./fs-test 37
> > subversion/tests/libsvn_fs/fs-test.c:4908: (apr_err=160033)
> > subversion/tests/svn_test_fs.c:183: (apr_err=160033)
> > subversion/tests/svn_test_fs.c:121: (apr_err=160033)
> > svn_tests: E160033: cannot create fs 'test-delete-fs' there is already a
> > directory of that name
> > subversion/libsvn_fs/fs-loader.c:515: (apr_err=160033)
> > subversion/libsvn_fs/fs-loader.c:322: (apr_err=160033)
> > subversion/libsvn_fs/fs-loader.c:162: (apr_err=160033)
> > svn_tests: E160033: Failed to load module for FS type 'bdb'
> > FAIL: fs-test 37: test svn_fs_delete_fs
> >
> > I suspect there's some boilerplate somewhere that was left out.
> >
> > -Hyrum
> >
> >
> > On Tue, Nov 20, 2012 at 6:52 AM, wrote:
> >
> >> Author: philip
> >> Date: Tue Nov 20 11:52:56 2012
> >> New Revision: 1411629
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1411629&view=rev
> >> Log:
> >> Explicitly test svn_fs_delete_fs.
> >>
> >> * subversion/tests/libsvn_fs/fs-test.c
> >> (delete_fs): New test.
> >> (test_list): Add new test.
> >>
> >> Modified:
> >> subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
> >>
> >> Modified: subversion/trunk/subversion/tests/libsvn_fs/fs-test.c
> >> URL:
> >> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/libsvn_fs/fs-test.c?rev=1411629&r1=1411628&r2=1411629&view=diff
> >>
> >> ==
> >> --- subversion/trunk/subversion/tests/libsvn_fs/fs-test.c (original)
> >> +++ subversion/trunk/subversion/tests/libsvn_fs/fs-test.c Tue Nov 20
> >> 11:52:56 2012
> >> @@ -4896,6 +4896,26 @@ node_history(const svn_test_opts_t *opts
> >>return SVN_NO_ERROR;
> >> }
> >>
> >> +/* Test svn_fs_delete_fs(). */
> >> +static svn_error_t *
> >> +delete_fs(const svn_test_opts_t *opts,
> >> + apr_pool_t *pool)
> >> +{
> >> + svn_fs_t *fs;
> >> + const char *path;
> >> + svn_node_kind_t kind;
> >> +
> >> + SVN_ERR(svn_test__create_fs(&fs, "test-delete-fs", opts, pool));
> >> + path = svn_fs_path(fs, pool);
> >> + SVN_ERR(svn_io_check_path(path, &kind, pool));
> >> + SVN_TEST_ASSERT(kind != svn_node_none);
> >> + SVN_ERR(svn_fs_delete_fs(path, pool));
> >> + SVN_ERR(svn_io_check_path(path, &kind, pool));
> >> + SVN_TEST_ASSERT(kind == svn_node_none);
> >> +
> >> + return SVN_NO_ERROR;
> >> +}
> >> +
> >>
> >>
> >> /*
> >> */
> >> @@ -4979,5 +4999,7 @@ struct svn_test_descriptor_t test_funcs[
> >> "create and modify small file"),
> >> SVN_TEST_OPTS_PASS(node_history,
> >> "test svn_fs_node_history"),
> >> +SVN_TEST_OPTS_PASS(delete_fs,
> >> + "test svn_fs_delete_fs"),
> >> SVN_TEST_NULL
> >>};
> >>
> >>
> >>
> >
