Re: [PATCH] Re: Diff Project compilation problem

2013-01-09 Thread Daniel Shahaf 
Gabriela Gibson wrote on Thu, Jan 10, 2013 at 00:15:29 +:
> I thought that the solutions to this question might be useful to have in  
> the faq.html.

> +There are a couple of frequent causes of this kind of problem:
> +
> +1.  You could be linking about your own installed libraries.

It would be useful to quote the error message.

Is this section applicable to tarball builds (which don't use
autogen.sh) too?

How does this compare to the HACKING (docs/community-guide/) section
containing Karl's "voice of experience" email?  Should they
crossreference each other?

> +Workaround 1: Remove them.
> +Workaround 2: "./configure --prefix=/usr/vladivostock ## Doesn't 
> exist"
> +
> +2.  You may have run "svn up" so that your build system is 
> now stale:
> +Rerun "./autogen.sh; make" or "./autogen.sh; 
> ./configure; make".

It would be useful to explain why this happens or what needs to be run
when.  IIRC the permutations are: if Makefile.in changed, re-run
configure to regenerate Makefile; if configure.ac or build/ac-macros/
changed, rerun autogen.sh to regenerate configure (then run configure);
if build.conf or build/gen-make/ changed, run ./gen-make.py (which is
normally invoked by autogen.sh) to regenerate build-outputs.mk.

> +
> +
> +
>  
>  References:
>

Re: [PATCH] Re: Diff Project compilation problem

2013-01-09 Thread Ben Reser 
On Wed, Jan 9, 2013 at 4:15 PM, Gabriela Gibson
 wrote:
> I thought that the solutions to this question might be useful to have in the
> faq.html.

> +1.  You could be linking about your own installed libraries.

Think you mean "You could be linking to your own installed libraries."

I'd probably flush this out a little section out a tad more.

> +Rerun "./autogen.sh; make" or "./autogen.sh; 
> ./configure; make".

Not sure if  is the right tag for command lines, think we've
been using  for that, but I believe  is going away and I'd bet
we've been inconsistent about that.

I'd probably say:
./autogen.sh; ./config.nice; make

config.nice is a script that configure writes after each run so you
can re-run configure with the same arguments, if you want to add
argument just pass it to config.nice.

[PATCH] Re: Diff Project compilation problem

2013-01-09 Thread Gabriela Gibson 
I thought that the solutions to this question might be useful to have in 
the faq.html.
Index: publish/faq.html
===
--- publish/faq.html	(revision 1431153)
+++ publish/faq.html	(working copy)
@@ -282,6 +282,8 @@ validating server certificate error even thou
 How do I run a debugger on
 Subversion binaries without compiler inlining obfuscating the
 source?
+How do I deal with compile errors in
+source tree which I can't explain by code changes?
 
 
 References:
@@ -4374,6 +4376,24 @@ installing Subversion from source, by re-running <
 
 
 
+
+How do I deal with compile errors in a source tree which I can't 
+explain by code changes?
+  ¶
+
+
+There are a couple of frequent causes of this kind of problem:
+
+1.  You could be linking about your own installed libraries.
+Workaround 1: Remove them.
+Workaround 2: "./configure --prefix=/usr/vladivostock ## Doesn't exist"
+
+2.  You may have run "svn up" so that your build system is now stale:
+Rerun "./autogen.sh; make" or "./autogen.sh; ./configure; make".
+
+
+
 
 References:
   [[[ 
Add advice to developer questions category on how to deal with compile errors
which are not explained by code changes.

* publish/faq.html:
  (table-of-contents): List question and add reference link to answer to 
   developer question section.
  (developer-questions): Add matching answer referred to in table-of-contents.

Patch by: Gabriela Gibson 
]]]

Re: svn commit: r1424708 - in /subversion/trunk/subversion: include/ libsvn_client/ libsvn_ra/ libsvn_wc/

2013-01-09 Thread Julian Foad 
Paul Burba wrote:

> On Thu, Dec 20, 2012 at 4:56 PM, Julian Foad wrote:
>>>  Author: pburba
>>>  Date: Thu Dec 20 21:19:08 2012
>>>  New Revision: 1424708
>>> 
>>>  URL: http://svn.apache.org/viewvc?rev=1424708&view=rev
>>>  Log:
>>>  Store repos root relative paths in NODES.INHERITED_PROPS rather than full
>>>  URLs.
>> 
>>  Glad to see this, overall.  One concern:
>> 
>>>  See http://svn.haxx.se/dev/archive-2012-12/0427.shtml
>>> 
>>>  * subversion/include/svn_ra.h
>>> 
>>>    (svn_ra_get_inherited_props): Add a new argument allowing the API to
>>>     retrieve an array of svn_prop_inherited_item_t items with the 
>>>     path_or_url member set to either a URL or (new) a repos relpath.
>> 
>>  Eww.  Can't we have this function do one thing and do it well?
>> 
>>  Let the higher layers convert to full URLs if they need to.
> 
> Agreed and done in r1430638.

Thanks, Paul.  Looks good.

- Julian

Re: svn commit: r1431072 - in /subversion/trunk/subversion: include/svn_types.h libsvn_client/copy.c libsvn_ra_serf/commit.c libsvn_subr/named_atomic.c libsvn_subr/stream.c mod_dav_svn/reports/replay.

2013-01-09 Thread Julian Foad 
Blair Zajac wrote:

> On 01/09/2013 01:02 PM, julianf...@apache.org wrote:
>>  Log:
>>  Consistify a few remaining redundant or odd expressions involving boolean
>>  constants, such as "foo == FALSE" to "!foo" and "number ? FALSE : TRUE" to
>>  "number != 0".  A follow-up to r1431017 and r1431040.
> 
> The commit is good and so is the comment on replay.c, but this should 
> read "number ? TRUE : FALSE" to be correct and match the code.

Oops.  I've edited the log.  Thanks.

- Julian

Re: svn commit: r1431072 - in /subversion/trunk/subversion: include/svn_types.h libsvn_client/copy.c libsvn_ra_serf/commit.c libsvn_subr/named_atomic.c libsvn_subr/stream.c mod_dav_svn/reports/replay.

2013-01-09 Thread Blair Zajac 

On 01/09/2013 01:02 PM, julianf...@apache.org wrote:

Author: julianfoad
Date: Wed Jan  9 21:02:33 2013
New Revision: 1431072

URL: http://svn.apache.org/viewvc?rev=1431072&view=rev
Log:
Consistify a few remaining redundant or odd expressions involving boolean
constants, such as "foo == FALSE" to "!foo" and "number ? FALSE : TRUE" to
"number != 0".  A follow-up to r1431017 and r1431040.


The commit is good and so is the comment on replay.c, but this should 
read "number ? TRUE : FALSE" to be correct and match the code.


Blair

Re: Diff Project compilation problem

2013-01-09 Thread Gabriela Gibson 

On 09/01/13 16:54, Philip Martin wrote:>
> ./configure --prefix=/usr/local/subversionx ...
>
> which solves the linking problem.  I never install this build so
> /usr/local/subversionx/lib never exists.  When I want to install a build
> of Subversion I reconfigure and rebuild using the correct prefix (and at
> this stage I may need to remove the Subversion libraries in the prefix
> to get it to link).
>
Thanks Philip. this did the trick.  And thanks to everyone else too!

Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c

2013-01-09 Thread Mark Phippard 
On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov  wrote:
> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato  
> wrote:
>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>> I'm thinking about interoperability between svn 1.8-serf client and
>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>> PROPFINDs and GETs for each file/directory. I've added option to
>>> advertise inline props support to leave possibility to use bulk
>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>> configuration for newer servers.
>>
>> Ah, I see.  So the client can say, "If you're going to force me to do a
>> zillion turnarounds, I'd rather take the all-in-one-response option,
>> please."  Seems reasonable.
>>
> Yes, that was my plan. The only argument that I found against this
> approach that we will have many different modes depending of
> server/client versions and configurations:
>
> client server behavior
> 1.8.x-serf  1.8.x   skelta-mode without
> propfinds (unless configured by server)
> 1.8.x-serf  1.7.x   bulk-mode
> 1.7.x-serf  1.7.x   skelta-mode with propfinds
> 1.7.x-neon1.7.x   bulk-mode
>
>
> But it makes sense: upgrading only one part (server or client) doesn't
> change network protocol, which is good thing IMHO.

+1 from me.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c

2013-01-09 Thread Ivan Zhakov 
On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato  wrote:
> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>> I'm thinking about interoperability between svn 1.8-serf client and
>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>> PROPFINDs and GETs for each file/directory. I've added option to
>> advertise inline props support to leave possibility to use bulk
>> (send-all) mode for pre-1.8 server by default, while relying on server
>> configuration for newer servers.
>
> Ah, I see.  So the client can say, "If you're going to force me to do a
> zillion turnarounds, I'd rather take the all-in-one-response option,
> please."  Seems reasonable.
>
Yes, that was my plan. The only argument that I found against this
approach that we will have many different modes depending of
server/client versions and configurations:

client server behavior
1.8.x-serf  1.8.x   skelta-mode without
propfinds (unless configured by server)
1.8.x-serf  1.7.x   bulk-mode
1.7.x-serf  1.7.x   skelta-mode with propfinds
1.7.x-neon1.7.x   bulk-mode


But it makes sense: upgrading only one part (server or client) doesn't
change network protocol, which is good thing IMHO.

-- 
Ivan Zhakov
VisualSVN Team

Re: svn commit: r1431017 - in /subversion/trunk: subversion/libsvn_delta/ subversion/libsvn_fs_base/ subversion/libsvn_fs_fs/ subversion/libsvn_ra_serf/ subversion/libsvn_ra_svn/ subversion/libsvn_rep

2013-01-09 Thread Stefan Fuhrmann 
On Wed, Jan 9, 2013 at 8:36 PM, Julian Foad wrote:

> Stefan,
>
>  > Log:
>
> > Coding style patch: in logical expressions, instead of comparing
> > with logical constants use arithmetic operations. I.e. replace
>
> No don't use arithmetic operations.  Maybe write, "In *boolean*
> expressions, instead of comparing with FALSE (or, worse, with TRUE), use
> *boolean* operators."
>
> The wording should be slightly better now.

>
> > Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> >
> ==
> > --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> > +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Wed Jan  9
> 19:24:52 2013
> > @@ -1304,9 +1304,9 @@ static svn_error_t *ra_svn_get_dir(svn_r
> > static svn_tristate_t
> > optbool_to_tristate(apr_uint64_t v)
> > {
> > -  if (v == TRUE)
> > +  if (v)
>
> No, no, not here!
>

You beat me by 2 minutes ;)


> >  return svn_tristate_true;
> > -  if (v == FALSE)
> > +  if (!v)
> >  return svn_tristate_false;
> >
> >return svn_tristate_unknown; /* Contains
> SVN_RA_SVN_UNSPECIFIED_NUMBER */
>
> Everything else looks correct.
>

Thanks for the review!

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c

2013-01-09 Thread C. Michael Pilato 
On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
> I'm thinking about interoperability between svn 1.8-serf client and
> pre-1.8 server: currently we use non-bulk skelta mode and this leads
> PROPFINDs and GETs for each file/directory. I've added option to
> advertise inline props support to leave possibility to use bulk
> (send-all) mode for pre-1.8 server by default, while relying on server
> configuration for newer servers.

Ah, I see.  So the client can say, "If you're going to force me to do a
zillion turnarounds, I'd rather take the all-in-one-response option,
please."  Seems reasonable.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c

2013-01-09 Thread Ivan Zhakov 
On Tue, Jan 8, 2013 at 6:55 PM, C. Michael Pilato  wrote:
> On 01/08/2013 04:20 AM, i...@apache.org wrote:
>> Author: ivan
>> Date: Tue Jan  8 09:20:54 2013
>> New Revision: 1430185
>>
>> URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
>> Log:
>> mod_dav_svn: Advertise if server supports sending properties in update
>> report in skelta mode.
>
> Ivan,
>
> What motivated this change?  You have the server advertising a subfeature of
> the REPORT functionality, and the client noting this fact, but the client
> isn't actually using the note.
>
> Besides that, it kinda breaks from the pattern we use for REPORT response
> functionality, which is that the client says "I want you to respond in X
> fashion if possible" and the server, in its response, says either "Sure,
> here's my X-style response..." or just "Here's my [implied non-X-style]
> response".  (See the "add_props_included" report baton member in
> libsvn_ra_serf/update.c, and the handling thereof.)
>
> The advertisement you've added seems only valuable if it would prevent a
> client from acting *at all* when the server does/doesn't support the inline
> properties.  Was that your intent?
>
Hi Mike,

I'm thinking about interoperability between svn 1.8-serf client and
pre-1.8 server: currently we use non-bulk skelta mode and this leads
PROPFINDs and GETs for each file/directory. I've added option to
advertise inline props support to leave possibility to use bulk
(send-all) mode for pre-1.8 server by default, while relying on server
configuration for newer servers.


-- 
Ivan Zhakov
VisualSVN Team

Re: svn commit: r1431017 - in /subversion/trunk: subversion/libsvn_delta/ subversion/libsvn_fs_base/ subversion/libsvn_fs_fs/ subversion/libsvn_ra_serf/ subversion/libsvn_ra_svn/ subversion/libsvn_rep

2013-01-09 Thread Julian Foad 
Stefan,

 > Log:

> Coding style patch: in logical expressions, instead of comparing
> with logical constants use arithmetic operations. I.e. replace

No don't use arithmetic operations.  Maybe write, "In *boolean* expressions, 
instead of comparing with FALSE (or, worse, with TRUE), use *boolean* 
operators."


> Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> ==
> --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Wed Jan  9 19:24:52 
> 2013
> @@ -1304,9 +1304,9 @@ static svn_error_t *ra_svn_get_dir(svn_r
> static svn_tristate_t
> optbool_to_tristate(apr_uint64_t v)
> {
> -  if (v == TRUE)
> +  if (v)

No, no, not here!

>      return svn_tristate_true;
> -  if (v == FALSE)
> +  if (!v)
>      return svn_tristate_false;
> 
>    return svn_tristate_unknown; /* Contains SVN_RA_SVN_UNSPECIFIED_NUMBER */

Everything else looks correct.

- Julian

Re: svn commit: r1430975 - /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs/low_level.c

2013-01-09 Thread Stefan Fuhrmann 
On Wed, Jan 9, 2013 at 8:11 PM, Branko Čibej  wrote:

> On 09.01.2013 20:00, Stefan Fuhrmann wrote:
> > On Wed, Jan 9, 2013 at 7:42 PM, Branko Čibej  > > wrote:
> >
> > On 09.01.2013 19:35, Ben Reser wrote:
> > > On Wed, Jan 9, 2013 at 10:00 AM, Branko Čibej
> > mailto:br...@wandisco.com>> wrote:
> > >> On 09.01.2013 18:54, stef...@apache.org
> >  wrote:
> > >>> -  if (header->is_delta)
> > >>> +  if (header->is_delta == FALSE)
> > >> Can we please use logical operators to test boolean values, not
> > >> arithmetic ones?
> >
> >
> > Hm. I somehow got the impression from other people's
> > code that they liked the more explicit version.
>
> Yah, I noticed some people prefer to code COBOL in C. :)
>
> > Personally, I prefer the shorter one.
>
> Agreed. Of course I expect this to escalate into a flamewar, but I'll
> note that while "== FALSE" is marginally acceptable, "== TRUE" is not,
> because of C's rules about truth values.
>

r1431017 has the flame bait.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: svn commit: r1430975 - /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs/low_level.c

2013-01-09 Thread Branko Čibej 
On 09.01.2013 20:00, Stefan Fuhrmann wrote:
> On Wed, Jan 9, 2013 at 7:42 PM, Branko Čibej  > wrote:
>
> On 09.01.2013 19:35, Ben Reser wrote:
> > On Wed, Jan 9, 2013 at 10:00 AM, Branko Čibej
> mailto:br...@wandisco.com>> wrote:
> >> On 09.01.2013 18:54, stef...@apache.org
>  wrote:
> >>> -  if (header->is_delta)
> >>> +  if (header->is_delta == FALSE)
> >> Can we please use logical operators to test boolean values, not
> >> arithmetic ones?
>
>
> Hm. I somehow got the impression from other people's
> code that they liked the more explicit version.

Yah, I noticed some people prefer to code COBOL in C. :)

> Personally, I prefer the shorter one.

Agreed. Of course I expect this to escalate into a flamewar, but I'll
note that while "== FALSE" is marginally acceptable, "== TRUE" is not,
because of C's rules about truth values.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: svn commit: r1430975 - /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs/low_level.c

2013-01-09 Thread Stefan Fuhrmann 
On Wed, Jan 9, 2013 at 7:42 PM, Branko Čibej  wrote:

> On 09.01.2013 19:35, Ben Reser wrote:
> > On Wed, Jan 9, 2013 at 10:00 AM, Branko Čibej 
> wrote:
> >> On 09.01.2013 18:54, stef...@apache.org wrote:
> >>> -  if (header->is_delta)
> >>> +  if (header->is_delta == FALSE)
> >> Can we please use logical operators to test boolean values, not
> >> arithmetic ones?
>

Hm. I somehow got the impression from other people's
code that they liked the more explicit version. Personally,
I prefer the shorter one.


> >> if (!header->is_delta)
> > There's quite a few examples of this in the code right now that we
> > should fix then
>
> Agreed -- we should fix them.
>

Ok. I'm on it right now. Being bored at the airport anyways ...

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
*

http://www.wandisco.com/subversion/download
*

Re: svn commit: r1430975 - /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs/low_level.c

2013-01-09 Thread Branko Čibej 
On 09.01.2013 19:35, Ben Reser wrote:
> On Wed, Jan 9, 2013 at 10:00 AM, Branko Čibej  wrote:
>> On 09.01.2013 18:54, stef...@apache.org wrote:
>>> -  if (header->is_delta)
>>> +  if (header->is_delta == FALSE)
>> Can we please use logical operators to test boolean values, not
>> arithmetic ones?
>>
>> if (!header->is_delta)
> There's quite a few examples of this in the code right now that we
> should fix then

Agreed -- we should fix them.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Re: svn commit: r1430975 - /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs/low_level.c

2013-01-09 Thread Ben Reser 
On Wed, Jan 9, 2013 at 10:00 AM, Branko Čibej  wrote:
> On 09.01.2013 18:54, stef...@apache.org wrote:
>>
>> -  if (header->is_delta)
>> +  if (header->is_delta == FALSE)
>
> Can we please use logical operators to test boolean values, not
> arithmetic ones?
>
> if (!header->is_delta)

There's quite a few examples of this in the code right now that we
should fix then

[[[
subversion/svn/svn.c:  if (descend == FALSE)
subversion/libsvn_subr/win32_crashrpt.c:  if (log_params == FALSE &&
sym_info->Flags & SYMFLAG_LOCAL)
subversion/libsvn_subr/win32_crashrpt.c:  if
(get_temp_filename(dmp_filename, LOGFILE_PREFIX, "dmp") == FALSE ||
subversion/libsvn_subr/win32_crashrpt.c:
get_temp_filename(log_filename, LOGFILE_PREFIX, "log") == FALSE)
subversion/libsvn_subr/win32_crashrpt.c:  if (load_dbghelp_dll() == FALSE)
subversion/libsvn_subr/deprecated.c:  if (have_options == FALSE)
subversion/libsvn_subr/subst.c:  if (keyword_matches == FALSE)
subversion/libsvn_subr/subst.c:  if (keyword_matches == FALSE ||
subversion/libsvn_subr/cmdline.c:  if (non_interactive == FALSE)
subversion/libsvn_subr/cmdline.c:  if (non_interactive == FALSE)
subversion/libsvn_subr/cmdline.c:  if (non_interactive == FALSE)
subversion/libsvn_subr/opt.c:  if (have_options == FALSE)
subversion/libsvn_ra_svn/client.c:  if (v == FALSE)
subversion/libsvn_repos/authz.c:
section_name) == FALSE
subversion/libsvn_repos/authz.c:
section_name) == FALSE)
subversion/libsvn_repos/fs-wrap.c:  if
(svn_utf__is_valid(value->data, value->len) == FALSE)
subversion/libsvn_repos/authz.c~:
section_name) == FALSE
subversion/libsvn_repos/authz.c~:
section_name) == FALSE)
subversion/libsvn_fs_fs/fs_fs.c~:  ((may_be_corrupt == FALSE ||
(checksum) != NULL) \
subversion/libsvn_fs_fs/fs_fs.c~:  if (ra->is_delta == FALSE)
subversion/libsvn_fs_fs/fs_fs.c~:  if (rep_args->is_delta == FALSE)
subversion/libsvn_fs_fs/fs_fs.c:  ((may_be_corrupt == FALSE ||
(checksum) != NULL) \
subversion/libsvn_fs_fs/fs_fs.c:  if (ra->is_delta == FALSE)
subversion/libsvn_fs_fs/fs_fs.c:  if (rep_args->is_delta == FALSE)
subversion/libsvn_fs_base/fs.c:  if (files_match == FALSE)
subversion/svnsync/svnsync.c:  if (!filter || filter(propname) == FALSE)
subversion/libsvn_ra_serf/property.c:  if (requested_allprop == FALSE)
subversion/libsvn_ra_serf/property.c:  if (requested_allprop == FALSE)
subversion/libsvn_ra_serf/locks.c:  if (ctx->read_headers == FALSE)
subversion/libsvn_ra_serf/util.c:  if (sl.code == 404 &&
ctx->ignore_errors == FALSE)
subversion/libsvn_ra_serf/update.c:  if
(fetch_ctx->aborted_read == FALSE && fetch_ctx->read_size)
subversion/libsvn_ra_serf/update.c:  if (fetch_ctx->read_headers == FALSE)
subversion/libsvn_ra_serf/update.c:  if (info->lock_token &&
info->fetch_props == FALSE)
subversion/libsvn_ra_serf/update.c:  if (report->closed_root ==
FALSE && report->root_dir != NULL)
subversion/tests/libsvn_subr/subst_translate-test.c:
SVN_TEST_ASSERT(translated_line_endings == FALSE);
subversion/tests/libsvn_subr/stream-test.c:  SVN_TEST_ASSERT(read_only
== FALSE);
subversion/tests/libsvn_subr/stream-test.c:  SVN_TEST_ASSERT(read_only
== FALSE);
subversion/tests/libsvn_wc/db-test.c:  SVN_TEST_ASSERT(had_props == FALSE);
subversion/tests/libsvn_wc/db-test.c:  SVN_TEST_ASSERT(had_props == FALSE);
subversion/tests/libsvn_wc/db-test.c:  SVN_TEST_ASSERT(props_mod == FALSE);
subversion/tests/libsvn_wc/db-test.c:  SVN_TEST_ASSERT(conflicted == FALSE);
subversion/libsvn_delta/svndiff.c:  if (eb->header_done == FALSE)
subversion/libsvn_delta/svndiff.c:  if (eb->header_done == FALSE)
tools/client-side/svn-bench/svn-bench.c:  if (descend == FALSE)
tools/client-side/svn-bench/main.c~:  if (descend == FALSE)
]]]

[[[
subversion/libsvn_ra_svn/client.c:  if (v == TRUE)
subversion/tests/libsvn_subr/subst_translate-test.c:
SVN_TEST_ASSERT(translated_to_utf8 == TRUE);
subversion/tests/libsvn_subr/string-test.c:  if
(svn_stringbuf_compare(a, b) == TRUE)
subversion/tests/libsvn_wc/db-test.c:  SVN_TEST_ASSERT(have_base == TRUE);
subversion/tests/libsvn_wc/db-test.c:  SVN_TEST_ASSERT(have_work == TRUE);
]]]

Re: sha-256 comment in /trunk/subversion/libsvn_subr/crypto.c

2013-01-09 Thread Ben Reser 
On Wed, Jan 9, 2013 at 6:39 AM, C. Michael Pilato  wrote:
> My state concern about our export status has, IIRC, been refuted.  But I
> need to find documentation of that refutation, and then remember to update
> the wiki.

I'm guessing that your concern here is with US export restrictions.
Incidentally, just committing the code to the ASF repo would be export
since it's mirrored to Europe.  However, I believe you qualify under
ECCN 5D002 and TSU exception in EAR 740.13(e).

Apache has a page covering this:
http://www.apache.org/dev/crypto.html

> Removing the code from trunk is fine, I suppose -- just means that when I
> next update my branch a bunch of supporting code will get blown away there,
> forcing me to re-add it.  But that's no big deal.  That kind of churn seems
> a bit unnecessary -- it is private, unused code after all.

Now that I think about it, I don't think it really matters if it is in
trunk or branch or a released code (by our definition) or not.  The
rules are the same either way.  So it's fine to leave it as far as I'm
concerned.  Someone just needs to do the footwork to comply.

Re: Diff Project compilation problem

2013-01-09 Thread Philip Martin 
Gabriela Gibson  writes:

> cd subversion/svnmucc && /bin/bash /home/g/trunk/libtool --tag=CC --silent 
> --mode=link gcc  -g3 -fno-omit-frame-pointer -fno-inline -Wall -Wmiss\
> ing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread 
> -DSVN_DEBUG -DAP_DEBUG   -rpath /usr/local/lib  -o svnmucc  svnmucc.lo ../.\
> ./subversion/libsvn_client/libsvn_client-1.la 
> ../../subversion/libsvn_ra/libsvn_ra-1.la 
> ../../subversion/libsvn_subr/libsvn_subr-1.la ../../subv\
> ersion/libsvn_delta/libsvn_delta-1.la -L/home/g/trunk/apr-util -laprutil-1 
> -L/home/g/trunk/apr -lapr-1
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference 
> to `svn_wc__get_wcroot'
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined reference 
> to `svn_wc_add_from_disk2'
> collect2: ld returned 1 exit status
> make: *** [subversion/svnmucc/svnmucc] Error 1

>From the rpath it looks like you are using the default --prefix of
/usr/local so the problem is probably that you have older Subversion
libraries installed in /usr/local/lib and the link is erroneously
picking up those libraries instead of the one in your build.  If you
remove the Subversion libraries from /usr/local/lib the link will
probably work.

Having to remove the installed libraries is obviously inconvenient,
particularly as they may well be the libraries that you are using.  The
way I work around this problem is that I do all my development using a
prefix that doesn't exist:

   ./configure --prefix=/usr/local/subversionx ...

which solves the linking problem.  I never install this build so
/usr/local/subversionx/lib never exists.  When I want to install a build
of Subversion I reconfigure and rebuild using the correct prefix (and at
this stage I may need to remove the Subversion libraries in the prefix
to get it to link).

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download

Re: Diff Project compilation problem

2013-01-09 Thread Stefan Sperling 
On Wed, Jan 09, 2013 at 04:31:05PM +, Gabriela Gibson wrote:
> I added a new option to the command structure and the compile error
> I get is this:
> 
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc__get_wcroot'
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc_add_from_disk2'
> 
> What is going on here?

I believe you're running into the problem where you've got some
released version of Subversion installed on your system, and
libtool is wrongly trying to link to the libsvn_wc from that
version, instead of linking to the proepr libsvn_wc which was
compiled in your working copy of Subversion trunk code.

So, this is not a problem with your patch. Rather, it is a problem
with how the build system interacts with existing software on your
system. It's a long-standing and annoying issue with libtool, where
it generates linker flags in the wrong order, causing the linker to
pick up Subversion libraries from the wrong directory.

It can be tricky to resolve such issues. The easiest option might
be to uninstall the other Subversion version, but that's not always
an option.

What operating system are you trying to compile on? Perhaps someone
who is using the same operating system can help you.

Re: Diff Project compilation problem

2013-01-09 Thread Hyrum K Wright 
On Wed, Jan 9, 2013 at 11:37 AM, Branko Čibej  wrote:

> On 09.01.2013 17:31, Gabriela Gibson wrote:
> > I added a new option to the command structure and the compile error I
> > get is this:
> >
> > ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> > reference to `svn_wc__get_wcroot'
> > ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> > reference to `svn_wc_add_from_disk2'
> >
> > What is going on here?  This is totally unexpected!  I grepped for the
> > terms and I cannot even see a connection %-)
> >
> > I attached a patch of the changes I made and the compile log is at the
> > bottom of this mail.
> >
> > I did make clean prior to this, and also make -k, the make here
> > was just to cut down the spammy list.
> >
> > thanks for any advice!
>
> I think you have to run autogen.sh again to rebuild the generated
> makefiles.


Even just ./gen-make.py should suffice.

fwiw, this probably isn't related to your change, just one that you picked
up upon running 'svn update'.

-Hyrum

Re: Diff Project compilation problem

2013-01-09 Thread Branko Čibej 
On 09.01.2013 17:31, Gabriela Gibson wrote:
> I added a new option to the command structure and the compile error I
> get is this:
>
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc__get_wcroot'
> ../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
> reference to `svn_wc_add_from_disk2'
>
> What is going on here?  This is totally unexpected!  I grepped for the
> terms and I cannot even see a connection %-)
>
> I attached a patch of the changes I made and the compile log is at the
> bottom of this mail.
>
> I did make clean prior to this, and also make -k, the make here
> was just to cut down the spammy list.
>
> thanks for any advice!

I think you have to run autogen.sh again to rebuild the generated makefiles.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com

Diff Project compilation problem

2013-01-09 Thread Gabriela Gibson 
I added a new option to the command structure and the compile error I 
get is this:


../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
reference to `svn_wc__get_wcroot'
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined
reference to `svn_wc_add_from_disk2'

What is going on here?  This is totally unexpected!  I grepped for the 
terms and I cannot even see a connection %-)


I attached a patch of the changes I made and the compile log is at the 
bottom of this mail.


I did make clean prior to this, and also make -k, the make here
was just to cut down the spammy list.

thanks for any advice!

-*- mode: compilation; default-directory: "/home/g/trunk/" -*-
Compilation started at Wed Jan  9 15:13:24

make
-- making all in apr
make[1]: Entering directory `/home/g/trunk/apr'
make[2]: Entering directory `/home/g/trunk/apr'
make[2]: Nothing to be done for `local-all'.
make[2]: Leaving directory `/home/g/trunk/apr'
make[1]: Leaving directory `/home/g/trunk/apr'
-- completed all in apr
-- making all in apr-util
make[1]: Entering directory `/home/g/trunk/apr-util'
make[2]: Entering directory `/home/g/trunk/apr-util'
make[2]: Nothing to be done for `local-all'.
make[2]: Leaving directory `/home/g/trunk/apr-util'
make[1]: Leaving directory `/home/g/trunk/apr-util'
-- completed all in apr-util
cd subversion/svnmucc && /bin/bash /home/g/trunk/libtool --tag=CC 
--silent --mode=link gcc  -g3 -fno-omit-frame-pointer -fno-inline -Wall 
-Wmiss\
ing-prototypes -Wstrict-prototypes -Wmissing-declarations -pthread 
-DSVN_DEBUG -DAP_DEBUG   -rpath /usr/local/lib  -o svnmucc  svnmucc.lo ../.\
./subversion/libsvn_client/libsvn_client-1.la 
../../subversion/libsvn_ra/libsvn_ra-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la ../../subv\
ersion/libsvn_delta/libsvn_delta-1.la -L/home/g/trunk/apr-util 
-laprutil-1 -L/home/g/trunk/apr -lapr-1
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined 
reference to `svn_wc__get_wcroot'
../../subversion/libsvn_client/.libs/libsvn_client-1.so: undefined 
reference to `svn_wc_add_from_disk2'

collect2: ld returned 1 exit status
make: *** [subversion/svnmucc/svnmucc] Error 1

Compilation exited abnormally with code 2 at Wed Jan  9 15:13:26
Index: subversion/libsvn_client/diff.c
===
--- subversion/libsvn_client/diff.c	(revision 1429564)
+++ subversion/libsvn_client/diff.c	(working copy)
@@ -583,6 +583,9 @@ struct diff_cmd_baton {
  relative to for output generation (see issue #2723). */
   const char *relative_to_dir;
 
+  /* GGTODO: Comment needed */
+  svn_boolean_t ignore_extensions;
+
   /* Whether property differences are ignored. */
   svn_boolean_t ignore_properties;
 
Index: subversion/libsvn_diff/diff_file.c
===
--- subversion/libsvn_diff/diff_file.c	(revision 1429564)
+++ subversion/libsvn_diff/diff_file.c	(working copy)
@@ -1172,7 +1172,7 @@ static const apr_getopt_option_t diff_options[] =
   { "ignore-all-space", 'w', 0, NULL },
   { "ignore-eol-style", SVN_DIFF__OPT_IGNORE_EOL_STYLE, 0, NULL },
   { "show-c-function", 'p', 0, NULL },
-  /* ### For compatibility; we don't support the argument to -u, because
+  /* ### Forcd compatibility; we don't support the argument to -u, because
* ### we don't have optional argument support. */
   { "unified", 'u', 0, NULL },
   { NULL, 0, 0, NULL }
Index: subversion/svn/cl.h
===
--- subversion/svn/cl.h	(revision 1429564)
+++ subversion/svn/cl.h	(working copy)
@@ -191,6 +191,7 @@ typedef struct svn_cl__opt_state_t
   svn_boolean_t notice_ancestry; /* notice ancestry for diff-y operations */
   svn_boolean_t summarize;   /* create a summary of a diff */
   svn_boolean_t use_git_diff_format; /* Use git's extended diff format */
+  svn_boolean_t ignore_extensions; /* ignore extention switches */
   svn_boolean_t ignore_properties; /* ignore properties */
   svn_boolean_t properties_only;   /* Show properties only */
   svn_boolean_t patch_compatible; /* Output compatible with GNU patch */
Index: subversion/svn/svn.c
===
--- subversion/svn/svn.c	(revision 1429564)
+++ subversion/svn/svn.c	(working copy)
@@ -80,6 +80,7 @@ typedef enum svn_cl__longopt_t {
   opt_notice_ancestry,
   opt_summarize,
   opt_use_git_diff_format,
+  opt_ignore_extensions,
   opt_ignore_properties,
   opt_properties_only,
   opt_patch_compatible,
@@ -185,6 +186,7 @@ const apr_getopt_option_t svn_cl__options[] =
   {"show-updates",  'u', 0, N_("display update information")},
   {"username",  opt_auth_username, 1, N_("specify a username ARG")},
   {"password",  opt_auth_password, 1, N_("specify a password ARG")},
+
   {"extensions",'x', 1,
 N_("Specify differencing options for external diff or\n"
"

Re: sha-256 comment in /trunk/subversion/libsvn_subr/crypto.c

2013-01-09 Thread C. Michael Pilato 
On 01/08/2013 07:53 PM, Ben Reser wrote:
> In this case I think this code should probably be removed from trunk
> for the time being.  The wiki for this functionality mentions that it
> may complicate our export control status.  If we're not using it we
> should probably remove it prior to 1.8 branching.  We can put it back
> later if we're ready to use it.

My state concern about our export status has, IIRC, been refuted.  But I
need to find documentation of that refutation, and then remember to update
the wiki.

Removing the code from trunk is fine, I suppose -- just means that when I
next update my branch a bunch of supporting code will get blown away there,
forcing me to re-add it.  But that's no big deal.  That kind of churn seems
a bit unnecessary -- it is private, unused code after all.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: Subversion & Windows

2013-01-09 Thread Justin Erenkrantz 
On Wed, Jan 9, 2013 at 3:30 AM, Branko Čibej  wrote:

> We talked about that a couple days ago, but the problem is that a
> Windows VM requires a Windows OS license for every user of that VM.
> That's not something we can provide or hack around (well ... we could
> hack around it, but it would be a really bad idea).
>

At least for committers, Microsoft makes an MSDN subscription
available...so, it's a tractable problem if our intention is to get more
committers voting for Windows releases (which, duh, is why Microsoft does
it in the first place!).  -- justin

Re: Subversion & Windows

2013-01-09 Thread Branko Čibej 
On 09.01.2013 07:32, Miha Vitorovic wrote:
> On 8.1.2013 21:28, Ben Reser wrote:
>> I think flat out the problem is that building on Windows is just a
>> pain.  I remember it took me several days to get a working build
>> environment so I could be the last signature on 1.6.19.  Unfortunately
>> I can't be the last vote on the more recent releases because I've been
>> the RM.
>>
>> There are several possible solutions to this problem.
>>
>> 1) We could lower the votes required for Windows.  It seems like we...
>>
>> 2) I could stop RM'ing.  That throws another person in the pool of...
>>
>> 3) WANdisco has non-committers building and testing the release...
>>
>> 4) One of the major problems with building Subversion on Windows is...
>>
>> 5) We could rewrite the build system to use something like CMake in...
>>
>> I expect the decision we make will be some combination of the above,
>> not just one of these choices.
> 6) You could create a VM appliance (with a dedicated maintainer), that
> anyone (of the testers) could download and know it contains everything
> necessary to build Subversion and run the tests. Unless the point of
> providing the signatures is making sure that Subversion builds on a
> variety Windows systems...

We talked about that a couple days ago, but the problem is that a
Windows VM requires a Windows OS license for every user of that VM.
That's not something we can provide or hack around (well ... we could
hack around it, but it would be a really bad idea).

-- Brane

-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com