Failed to build 1.7.0-beta3 on IBM AIX 5.3

PLATFORM: IBM AIX 5.3 (PPC 32bit) $ uname -a AIX myaixserver 3 5 0005D57A4C00 COMPONENTS: apr-1.4.5 apr-iconv-1.2.1 apr-util-1.3.12 sqlite-amalgamation-3070701 zlib-1.2.5 CONFIGURATIONS: ./configure --prefix=/home/citest/target/svn \ --enable-all-static \ --disable-shared \ --disable

ra_serf testing (was: svn commit: r1158522 - /subversion/branches/1.7.x/STATUS)

On Wed, Aug 17, 2011 at 01:30, wrote: > Author: gstein > Date: Wed Aug 17 05:30:23 2011 > New Revision: 1158522 > > URL: http://svn.apache.org/viewvc?rev=1158522&view=rev > Log: > IMO, issue 3979 should be fixed if ra_serf is the default, but we're too > late in the cycle for the necessary work.

Re: [VOTE]: Default http-client for 1.7 Serf or Neon

On Fri, Aug 5, 2011 at 06:18, Philip Martin wrote: > Greg Stein writes: > >> Right. That pretty much summarizes my feeling. I don't want to respond >> in-line since you summarize it well: without real-life examples, we >> have nothing to work against here. > > So I've put some of the concerns in

RE: svn cross-repo copy loses svn:executable *and* leaves the working dir inconsistent

> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: woensdag 17 augustus 2011 0:22 > To: Mark Eichin > Cc: dev@subversion.apache.org > Subject: Re: svn cross-repo copy loses svn:executable *and* leaves the > working dir inconsistent > > I can reproduce thi

Re: svn cross-repo copy loses svn:executable *and* leaves the working dir inconsistent

I can reproduce this with trunk. Mark Eichin wrote on Tue, Aug 16, 2011 at 17:54:57 -0400: > Ran across this while writing a "populate new repo" script, that used > svn cp to copy a set of svn-hooks in place (by definition from one > repo to another.) What happens is that when a file in the sourc

Re: JavaHL Bug: cannot propedit versioned props by URL

Thanks Hyrum! I committed the test and nominated all three revisions for 1.7.x. On Tue, Aug 16, 2011 at 4:35 PM, Hyrum K Wright wrote: > r1158436 allows you to specify the base revision for the URL to > satisfy the underlying API requirements. I didn't commit the test. > > (I assume that once

svn cross-repo copy loses svn:executable *and* leaves the working dir inconsistent

Ran across this while writing a "populate new repo" script, that used svn cp to copy a set of svn-hooks in place (by definition from one repo to another.) What happens is that when a file in the source repo (called "foreign" here) has svn:executable set, the working dir in the destination (called

Re: Did we have ^/clients?

No worries, thanks for confirming, documented in r1158438. C. Michael Pilato wrote on Tue, Aug 16, 2011 at 15:55:02 -0400: > On 08/16/2011 02:58 PM, Daniel Shahaf wrote: > > Arfrever found: > > > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=251335 > > http://subversi

Re: JavaHL Bug: cannot propedit versioned props by URL

r1158436 allows you to specify the base revision for the URL to satisfy the underlying API requirements. I didn't commit the test. (I assume that once the test and other fixes are in place, the whole lot will be nominated for 1.7.x.) -Hyrum On Tue, Aug 16, 2011 at 2:28 PM, Mark Phippard wrote:

svn:// over ra_dav

Looking at , the current suggestion there is to implement multiple-locks-in-one-request by POSTing to the me resource. The POST handler is already implemented --- it slurps the request body, parses a skel and calls a callback with the remai

Re: Did we have ^/clients?

On 08/16/2011 02:58 PM, Daniel Shahaf wrote: > Arfrever found: > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=251335 > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=251328 > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMess

Re: JavaHL Bug: cannot propedit versioned props by URL

Attaching this time ... On Tue, Aug 16, 2011 at 3:26 PM, Mark Phippard wrote: > On Tue, Aug 16, 2011 at 3:09 PM, Hyrum K Wright > wrote: > >> On Tue, Aug 16, 2011 at 11:59 AM, Mark Phippard >> wrote: >> > The JavaHL propertySetRemote API seems incomplete. >> > 1) It does not take a CommitMessa

Re: JavaHL Bug: cannot propedit versioned props by URL

On Tue, Aug 16, 2011 at 3:09 PM, Hyrum K Wright wrote: > On Tue, Aug 16, 2011 at 11:59 AM, Mark Phippard > wrote: > > The JavaHL propertySetRemote API seems incomplete. > > 1) It does not take a CommitMessageCallback. So no way to provide commit > > message. > > r1158421 added the CommitMessage

Re: JavaHL Bug: cannot propedit versioned props by URL

On Tue, Aug 16, 2011 at 11:59 AM, Mark Phippard wrote: > The JavaHL propertySetRemote API seems incomplete. > 1) It does not take a CommitMessageCallback.  So no way to provide commit > message. r1158421 added the CommitMessageCallback to the propertSetRemote API. > 2) When trying to change a v

Re: Did we have ^/clients?

Arfrever found: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=251335 http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=251328 http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=251344 Subject lines "svn.collab.net is going do

Re: Did we have ^/clients?

Greg Hudson writes: >I remember svn (the command) living under subversion/clients/svn and >being moved to subversion/svn. That's "/trunk/subversion/clients/", which we also discussed in IRC, but is separate from "/clients" (note the lack of "trunk/"). >If there's no evidence of this in our Subve

Re: Did we have ^/clients?

Daniel Shahaf writes: >r6881 implies that a ^/clients directory existed until r6880: >https://svn.apache.org/viewvc/subversion/README?r1=846955&r2=846954&pathrev=846955&diff_format=f > >kfogel on IRC recalls it having existed. > >However, the ASF repository does not have a ^/subversion/clients tre

Re: Did we have ^/clients?

Daniel Shahaf wrote on Tue, Aug 16, 2011 at 21:14:29 +0300: > Did a ^/clients directory exist? If yes, where is its history? Bert found http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=227683 which shows r5945 touching (presumably ^/)clients/rapidsvn. But the correspondin

Re: Did we have ^/clients?

On Tue, Aug 16, 2011 at 1:21 PM, Greg Hudson wrote: > On Tue, 2011-08-16 at 14:14 -0400, Daniel Shahaf wrote: >> r6881 implies that a ^/clients directory existed until r6880: >> https://svn.apache.org/viewvc/subversion/README?r1=846955&r2=846954&pathrev=846955&diff_format=f >> >> kfogel on IRC rec

Re: Did we have ^/clients?

On Tue, 2011-08-16 at 14:14 -0400, Daniel Shahaf wrote: > r6881 implies that a ^/clients directory existed until r6880: > https://svn.apache.org/viewvc/subversion/README?r1=846955&r2=846954&pathrev=846955&diff_format=f > > kfogel on IRC recalls it having existed. I remember svn (the command) livi

Did we have ^/clients?

r6881 implies that a ^/clients directory existed until r6880: https://svn.apache.org/viewvc/subversion/README?r1=846955&r2=846954&pathrev=846955&diff_format=f kfogel on IRC recalls it having existed. However, the ASF repository does not have a ^/subversion/clients tree anywhere in its history[1],

RE: Problems compiling 1.7.0 on redhat el4 64bit

Disabling optimizations is definitely an option. I should check to see if disabling optimizations just for the one problem file makes the issue go away. No reason to disable optimizations for all files if necessary. We have decided to only compile for 32bit and use that on all our 32 and 64 bi

JavaHL Bug: cannot propedit versioned props by URL

The JavaHL propertySetRemote API seems incomplete. 1) It does not take a CommitMessageCallback. So no way to provide commit message. 2) When trying to change a versioned property via URL, it fails with: Bogus revision information given svn: Setting property on non-local targets needs a base rev

Re: Problems compiling 1.7.0 on redhat el4 64bit

On Tue, Aug 16, 2011 at 10:25 AM, Mark Phippard wrote: > Where do we stand on this?  I have not seen anyone propose the obvious fix > which would be to reverse the commit that caused the problem.  Do we really > need this optimization if it can segfault with the wrong compiler settings? > As menti

Re: svn commit: r1157682 - /subversion/trunk/subversion/svn/status.c

> - moved_from_line = apr_psprintf(pool, "\n> %s %s", > - _("moved from"), relpath); > + moved_from_line = apr_psprintf(pool, > + apr_psprintf(pool, > + "\n

Re: Problems compiling 1.7.0 on redhat el4 64bit

On 16.08.2011 17:25, Mark Phippard wrote: > Where do we stand on this? I have not seen anyone propose the obvious > fix which would be to reverse the commit that caused the problem. Do > we really need this optimization if it can segfault with the wrong > compiler settings? Has anyone tried comp

Re: Problems compiling 1.7.0 on redhat el4 64bit

Where do we stand on this? I have not seen anyone propose the obvious fix which would be to reverse the commit that caused the problem. Do we really need this optimization if it can segfault with the wrong compiler settings? As mentioned before, we saw this same problem in the Linux RPM's that w

Re: [Issue 3093] svn_ra_neon__get_dir returns wrong directory set with public URL

danie...@tigris.org wrote on Tue, Aug 16, 2011 at 07:25:44 -0700: > http://subversion.tigris.org/issues/show_bug.cgi?id=3093 > > > > User danielsh changed the following: > > What|Old value |New value > =

Re: private functions in public api?

On 08/15/2011 10:52 AM, Julian Foad wrote: > On Sun, 2011-08-14, Neels J Hofmeyr wrote: >> There are double-underscored function names in include/svn_dirent_uri.h (and >> in other include/*.h, too), found both on trunk and on 1.7.x, as well as in >> recent beta releases. Have our naming conventions

Re: Ctypes-python Array class self-reference problem

I'm having trouble getting even 'Array(c_void_p)' to work. It either outputs nothing and opens a new line with another >>> prompt, that has some functionality disabled (eg, prompt history), or complains >>> x = Array(c_void_p, []) Traceback (most recent call last): File "", line 1, in TypeError