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-nls \
 --with-apr=/home/citest/target/apr \
 --with-apr-util=/home/citest/target/apr-util \
 --without-neon \
 --without-serf \
 --without-gssapi \
 --without-berkeley-db\
 --with-zlib=/home/citest/target/zlib

RESULT LOG:
...
cd subversion/svn && /bin/sh
/home/citest/subversion-1.7.0-beta3/libtool --tag=CC --silent
--mode=link gcc -all-static -static  -g -O2  -g -O2 -pthread
-Werror=implicit-function-declaration   -rpath
/home/citest/target/svn/lib  -o svn  add-cmd.lo blame-cmd.lo
cat-cmd.lo changelist-cmd.lo checkout-cmd.lo cleanup-cmd.lo
commit-cmd.lo conflict-callbacks.lo copy-cmd.lo delete-cmd.lo
diff-cmd.lo export-cmd.lo help-cmd.lo import-cmd.lo info-cmd.lo
list-cmd.lo lock-cmd.lo log-cmd.lo main.lo merge-cmd.lo
mergeinfo-cmd.lo mkdir-cmd.lo move-cmd.lo notify.lo patch-cmd.lo
propdel-cmd.lo propedit-cmd.lo propget-cmd.lo proplist-cmd.lo props.lo
propset-cmd.lo relocate-cmd.lo resolve-cmd.lo resolved-cmd.lo
revert-cmd.lo status-cmd.lo status.lo switch-cmd.lo tree-conflicts.lo
unlock-cmd.lo update-cmd.lo upgrade-cmd.lo util.lo
../../subversion/libsvn_client/libsvn_client-1.la
../../subversion/libsvn_wc/libsvn_wc-1.la
../../subversion/libsvn_ra/libsvn_ra-1.la
../../subversion/libsvn_delta/libsvn_delta-1.la
../../subversion/libsvn_diff/libsvn_diff-1.la
../../subversion/libsvn_subr/libsvn_subr-1.la
-L/home/citest/target/apr-util/lib -laprutil-1 -lexpat -liconv
-L/home/citest/target/apr/lib -lapr-1 -lpthread
ld: 0711-317 ERROR: Undefined symbol: .compressBound
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make: 1254-004 The error code from the last command is 1.

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

[Greg Stein]

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. Ship with Neon.

I would like to be very clear about something here:

The bugs that arrived "last minute" are (IMO) due to a failing in the
community to properly test ra_serf. And now we have kicked the damned
can down the road. I fear that we're going to run into the same
fuckin' problem when we try to ship 1.8, and it makes me cranky.

Configure your client with ra_serf. Disable Neon. Test it. And if you
have a problem, then FILE A BUG. Do it.

We need serf to properly deal with our goal of "request only the
pristines (by SHA) that we need". Failing to properly test ra_serf
impacts our future direction. PLEASE: no more of this "test at last
minute" crap that has happened.

-g

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

[Greg Stein]

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 the issue tracker:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3979
> http://subversion.tigris.org/issues/show_bug.cgi?id=3980
> http://subversion.tigris.org/issues/show_bug.cgi?id=3981

Thank you. As Daniel stated, if the issues are not raised, then they
are *not* issues/blockers.

Per my comments in 3979, I feel that one is the most critical. I
believe that we need to probe the server to determine whether some
broken crap has been interposed. I'm of a mind to say "fix your shit",
but also know that we can do something to work around the problem.
Justin's patch is interesting, but I believe it "happens to work", and
a higher-level solution is needed.

I also believe that 3980 is simply server-misconfiguration:
servers/proxies need to enable caching to get the wins that ra_serf
should make possible (with no loss to users who continue to use
ra_neon).

>...

Cheers,
-g

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

[Bert Huijben]

> -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 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 source repo
> > (called "foreign" here) has svn:executable set, the working dir in the
> > destination (called "local" here) looks right - ls -l shows the +x
> > bits, svn proplist -v shows the property, even .svn/props-base
> > mentions it.  The commit, on the other hand, doesn't push it to the
> > repository.  This means that the local checkout is now a "persistent
> > lie" (in that trying to set it there and commit it does nothing,
> > because it's "already" set.)
> 
> So, it's definitely a bug *somewhere*.

.svn/props-base shouldn't have any properties on a cross-repo copy/merge.

And that there are pristine properties for a local addition also explains
why the property changes aren't pushed on commit: the working copy doesn't
see them as changes.

> > svn co $LOCAL_REPO/branch $PERFORM_COPY_WORKDIR/branch
> > svn copy $FOREIGN_REPO/trunk/program
> $PERFORM_COPY_WORKDIR/branch/copied-program
> 
> Is this documented to work?

Bert

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

[Daniel Shahaf]

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 source repo
> (called "foreign" here) has svn:executable set, the working dir in the
> destination (called "local" here) looks right - ls -l shows the +x
> bits, svn proplist -v shows the property, even .svn/props-base
> mentions it.  The commit, on the other hand, doesn't push it to the
> repository.  This means that the local checkout is now a "persistent
> lie" (in that trying to set it there and commit it does nothing,
> because it's "already" set.)

So, it's definitely a bug *somewhere*.

> svn co $LOCAL_REPO/branch $PERFORM_COPY_WORKDIR/branch
> svn copy $FOREIGN_REPO/trunk/program 
> $PERFORM_COPY_WORKDIR/branch/copied-program

Is this documented to work?

Re: JavaHL Bug: cannot propedit versioned props by URL

[Mark Phippard]

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 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:
> > 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 CommitMessageCallback.  So no way to provide
> >>> > commit
> >>> > message.
> >>>
> >>>  r1158421 added the CommitMessageCallback to the propertSetRemote API.
> >>>
> >>> > 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 revision
> >>> > We want to use this API in Subclipse to freeze svn:externals
> properties
> >>> > in a
> >>> > tag after committing it.  TortoiseSVN seems to offer to do this now.
> >>>
> >>> I'm not sure exactly what's going on here, or how to trigger it.  If
> >>> possible, a test case would go a long way toward illuminating this.
> >>
> >> I have attached a patch that adds a new test that shows the problem.
> When
> >> this is working I would probably enhance the test to update the WC and
> >> verify the prop change.
> >> When I run the test with current trunk it fails with this:
> >> There was 1 error:
> >> 1)
> >>
> testPropEdit(org.apache.subversion.javahl.BasicTests)org.apache.subversion.javahl.ClientException:
> >> Bogus revision information given
> >> svn: Setting property on non-local targets needs a base revision
> >> at native.subversion.libsvn_client(prop_commands.c:418)
> >> at org.apache.subversion.javahl.SVNClient.propertySetRemote(Native
> Method)
> >> at
> >>
> org.apache.subversion.javahl.BasicTests.testPropEdit(BasicTests.java:3146)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >> at org.apache.subversion.javahl.RunTests.main(RunTests.java:116)
> >> FAILURES!!!
> >> Tests run: 1,  Failures: 0,  Errors: 1
> >>
> >> --
> >> Thanks
> >>
> >> Mark Phippard
> >> http://markphip.blogspot.com/
> >
> >
> >
> > --
> > Thanks
> >
> > Mark Phippard
> > http://markphip.blogspot.com/
> >
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
>



-- 
Thanks

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

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

[Mark Eichin]

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 "local" here) looks right - ls -l shows the +x
bits, svn proplist -v shows the property, even .svn/props-base
mentions it.  The commit, on the other hand, doesn't push it to the
repository.  This means that the local checkout is now a "persistent
lie" (in that trying to set it there and commit it does nothing,
because it's "already" set.)  A fresh checkout of the result shows the
bits missing, though.

I'm doing copy from url to working dir because in practice, I need to
do some variable substitution before pushing the file to the new repo;
that substitution isn't in the script because without it, the bug
still happens.

I've only tested this on "svn, version 1.6.12 (r955767) - compiled Jun
 5 2011, 14:55:20"  which is 1.6.12dfsg-1ubuntu1.3 from Ubuntu 10.10
(maverick.)  Also, while the test is between two locally built repos
with file:// urls, I originally saw the problem going between https://
and svn+ssh:// which distracted me :-)  So I'd appreciate if people
who can conveniently do so would test this on newer versions.  Thanks.


#!/bin/sh -e


LOCAL_REPO_DIR=/tmp/svn-propcopy-repo-local
FOREIGN_REPO_DIR=/tmp/svn-propcopy-repo-foreign
PREP_FOREIGN_WORKDIR=/tmp/svn-propcopy-work-prep
PERFORM_COPY_WORKDIR=/tmp/svn-propcopy-work-copy
SHOW_FAILURE_WORKDIR=/tmp/svn-propcopy-work-show
rm -rf $LOCAL_REPO_DIR
rm -rf $FOREIGN_REPO_DIR
rm -rf $PREP_FOREIGN_WORKDIR; mkdir -p $PREP_FOREIGN_WORKDIR
rm -rf $PERFORM_COPY_WORKDIR; mkdir -p $PERFORM_COPY_WORKDIR
rm -rf $SHOW_FAILURE_WORKDIR; mkdir -p $SHOW_FAILURE_WORKDIR

echo  create two repos: one local, 
svnadmin create $LOCAL_REPO_DIR
LOCAL_REPO=file:$LOCAL_REPO_DIR
svn mkdir -m 'trunk' $LOCAL_REPO/trunk
svn mkdir -m 'branch' $LOCAL_REPO/branch
echo  one '"foreign"' 
svnadmin create $FOREIGN_REPO_DIR
FOREIGN_REPO=file:$FOREIGN_REPO_DIR
svn mkdir -m 'trunk 2' $FOREIGN_REPO/trunk
svn mkdir -m 'branch 2' $FOREIGN_REPO/branch

echo  Create an executable file in the foreign repo. 
svn co $FOREIGN_REPO/trunk $PREP_FOREIGN_WORKDIR/trunk
cat > $PREP_FOREIGN_WORKDIR/trunk/program < 

Re: Did we have ^/clients?

[Daniel Shahaf]

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://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 down for a bit."
> > "Client source code migration [gsvn, rapidsvn]"
> > "svn commit: rev 6880 - clients"
> > 
> > which collectively indicate that:
> > 
> > * ^/clients existed
> > * it contained rapidsvn, winsvn, gsvn
> > * it was removed in r6880
> > * the history was moved to new repositories, and removed from the
> >   s.c.n/repos/svn repository
> 
> The results of your archaeological expedition match the echoes of what
> memories I have of those events.  (Sorry for not seeing your mail earlier
> and saving you the hunt.)
> 
> > Aside from this, I recall at least one more instance where history was
> > munged: prior to the 1.5.0 release, when svn:mergeinfo generated by
> > 1.5-dev clients were retroactively modified.  Were there additional
> > instances?
> 
> I can't currently recall any additional instances of history munging.
> 
> -- 
> C. Michael Pilato 
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: JavaHL Bug: cannot propedit versioned props by URL

[Hyrum K Wright]

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:
> 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 CommitMessageCallback.  So no way to provide
>>> > commit
>>> > message.
>>>
>>>  r1158421 added the CommitMessageCallback to the propertSetRemote API.
>>>
>>> > 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 revision
>>> > We want to use this API in Subclipse to freeze svn:externals properties
>>> > in a
>>> > tag after committing it.  TortoiseSVN seems to offer to do this now.
>>>
>>> I'm not sure exactly what's going on here, or how to trigger it.  If
>>> possible, a test case would go a long way toward illuminating this.
>>
>> I have attached a patch that adds a new test that shows the problem. When
>> this is working I would probably enhance the test to update the WC and
>> verify the prop change.
>> When I run the test with current trunk it fails with this:
>> There was 1 error:
>> 1)
>> testPropEdit(org.apache.subversion.javahl.BasicTests)org.apache.subversion.javahl.ClientException:
>> Bogus revision information given
>> svn: Setting property on non-local targets needs a base revision
>> at native.subversion.libsvn_client(prop_commands.c:418)
>> at org.apache.subversion.javahl.SVNClient.propertySetRemote(Native Method)
>> at
>> org.apache.subversion.javahl.BasicTests.testPropEdit(BasicTests.java:3146)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at org.apache.subversion.javahl.RunTests.main(RunTests.java:116)
>> FAILURES!!!
>> Tests run: 1,  Failures: 0,  Errors: 1
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>



-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

svn:// over ra_dav

[Daniel Shahaf]

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
remainder of the skel --- and it has one user already (implemented for
both ra_neon and ra_serf).

Given the above, implementing #2263 does look like a straightforward
exercise.  However, it would require a custom skel-based request format
for the body.  Couldn't we use the ra_svn lock-many request for that?

And, if we could...

Couldn't we take this one step further and write a POST handler that,
essentially, acts as an ra_svn proxy --- grabbing a POST request from
the network and passing it unmodified to ../svnserve/serve.c?

---

So, this may be an absurd conclusion, but I would feel ridiculous
implementing a skel-based solution for a problem that we have
a known-good ra_svn-tuples-based solutions for.
Index: subversion/mod_dav_svn/repos.c
===
--- subversion/mod_dav_svn/repos.c  (revision 1158271)
+++ subversion/mod_dav_svn/repos.c  (working copy)
@@ -4420,6 +4420,10 @@ handle_post_request(request_rec *r,
 {
   return dav_svn__post_create_txn(resource, request_skel, output);
 }
+  else if (svn_skel__matches_atom(request_skel->children, "ra-svn"))
+{
+  return (../svnserve/serve.c:serve)(resource, 
request_skel->children->next, output);
+}
   else
 {
   return dav_svn__new_error(pool, HTTP_BAD_REQUEST, 0,

Re: Did we have ^/clients?

[C. Michael Pilato]

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&dsMessageId=251344
> 
> Subject lines
> "svn.collab.net is going down for a bit."
> "Client source code migration [gsvn, rapidsvn]"
> "svn commit: rev 6880 - clients"
> 
> which collectively indicate that:
> 
> * ^/clients existed
> * it contained rapidsvn, winsvn, gsvn
> * it was removed in r6880
> * the history was moved to new repositories, and removed from the
>   s.c.n/repos/svn repository

The results of your archaeological expedition match the echoes of what
memories I have of those events.  (Sorry for not seeing your mail earlier
and saving you the hunt.)

> Aside from this, I recall at least one more instance where history was
> munged: prior to the 1.5.0 release, when svn:mergeinfo generated by
> 1.5-dev clients were retroactively modified.  Were there additional
> instances?

I can't currently recall any additional instances of history munging.

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

Re: JavaHL Bug: cannot propedit versioned props by URL

[Mark Phippard]

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 CommitMessageCallback.  So no way to provide
>> commit
>> > message.
>>
>>  r1158421 added the CommitMessageCallback to the propertSetRemote API.
>>
>> > 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 revision
>> > We want to use this API in Subclipse to freeze svn:externals properties
>> in a
>> > tag after committing it.  TortoiseSVN seems to offer to do this now.
>>
>> I'm not sure exactly what's going on here, or how to trigger it.  If
>> possible, a test case would go a long way toward illuminating this.
>>
>
> I have attached a patch that adds a new test that shows the problem. When
> this is working I would probably enhance the test to update the WC and
> verify the prop change.
>
> When I run the test with current trunk it fails with this:
>
> There was 1 error:
> 1)
> testPropEdit(org.apache.subversion.javahl.BasicTests)org.apache.subversion.javahl.ClientException:
> Bogus revision information given
> svn: Setting property on non-local targets needs a base revision
>
> at native.subversion.libsvn_client(prop_commands.c:418)
>  at org.apache.subversion.javahl.SVNClient.propertySetRemote(Native
> Method)
> at
> org.apache.subversion.javahl.BasicTests.testPropEdit(BasicTests.java:3146)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>  at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.apache.subversion.javahl.RunTests.main(RunTests.java:116)
>
> FAILURES!!!
> Tests run: 1,  Failures: 0,  Errors: 1
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/
Index: 
subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java
===
--- 
subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java   
(revision 1158424)
+++ 
subversion/bindings/javahl/tests/org/apache/subversion/javahl/BasicTests.java   
(working copy)
@@ -3110,6 +3110,46 @@
 }
 
 /**
+ * Test the basic SVNClient.propertySetRemote functionality.
+ * @throws Throwable
+ */
+public void testPropEdit() throws Throwable
+{
+   final String PROP = "abc";
+   final byte[] VALUE = new String("def").getBytes();
+   final byte[] NEWVALUE = new String("newvalue").getBytes();
+// create the test working copy
+OneTest thisTest = new OneTest();
+
+Set pathSet = new HashSet();
+// set a property on A/D/G/rho file
+pathSet.clear();
+pathSet.add(thisTest.getWCPath()+"/A/D/G/rho");
+client.propertySetLocal(pathSet, PROP, VALUE,
+Depth.infinity, null, false);
+thisTest.getWc().setItemPropStatus("A/D/G/rho", Status.Kind.modified);
+
+// test the status of the working copy
+thisTest.checkStatus();
+
+// commit the changes
+checkCommitRevision(thisTest, "wrong revision number from commit", 2,
+thisTest.getWCPathSet(), "log msg", Depth.infinity,
+false, false, null, null);
+
+thisTest.getWc().setItemPropStatus("A/D/G/rho", Status.Kind.normal);
+
+// check the status of the working copy
+thisTest.checkStatus();
+
+// now edit the propval directly in the repository
+client.propertySetRemote(thisTest.getUrl()+"/A/D/G/rho", PROP, 
NEWVALUE, new ConstMsg("edit prop"),
+ false, null, null);
+
+
+}
+
+/**
  * Test tolerance of unversioned obstructions when adding paths with
  * {@link org.apache.subversion.javahl.SVNClient#checkout()},
  * {@link org.apache.subversion.javahl.SVNClient#update()}, and

Re: JavaHL Bug: cannot propedit versioned props by URL

[Mark Phippard]

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 CommitMessageCallback to the propertSetRemote API.
>
> > 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 revision
> > We want to use this API in Subclipse to freeze svn:externals properties
> in a
> > tag after committing it.  TortoiseSVN seems to offer to do this now.
>
> I'm not sure exactly what's going on here, or how to trigger it.  If
> possible, a test case would go a long way toward illuminating this.
>

I have attached a patch that adds a new test that shows the problem. When
this is working I would probably enhance the test to update the WC and
verify the prop change.

When I run the test with current trunk it fails with this:

There was 1 error:
1)
testPropEdit(org.apache.subversion.javahl.BasicTests)org.apache.subversion.javahl.ClientException:
Bogus revision information given
svn: Setting property on non-local targets needs a base revision

at native.subversion.libsvn_client(prop_commands.c:418)
at org.apache.subversion.javahl.SVNClient.propertySetRemote(Native Method)
at
org.apache.subversion.javahl.BasicTests.testPropEdit(BasicTests.java:3146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.subversion.javahl.RunTests.main(RunTests.java:116)

FAILURES!!!
Tests run: 1,  Failures: 0,  Errors: 1


-- 
Thanks

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

Re: JavaHL Bug: cannot propedit versioned props by URL

[Hyrum K Wright]

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 versioned property via URL, it fails with:
> Bogus revision information given
> svn: Setting property on non-local targets needs a base revision
> We want to use this API in Subclipse to freeze svn:externals properties in a
> tag after committing it.  TortoiseSVN seems to offer to do this now.

I'm not sure exactly what's going on here, or how to trigger it.  If
possible, a test case would go a long way toward illuminating this.

Thanks,
-Hyrum


-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Re: Did we have ^/clients?

[Daniel Shahaf]

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 down for a bit."
"Client source code migration [gsvn, rapidsvn]"
"svn commit: rev 6880 - clients"

which collectively indicate that:

* ^/clients existed
* it contained rapidsvn, winsvn, gsvn
* it was removed in r6880
* the history was moved to new repositories, and removed from the
  s.c.n/repos/svn repository

...

Aside from this, I recall at least one more instance where history was
munged: prior to the 1.5.0 release, when svn:mergeinfo generated by
1.5-dev clients were retroactively modified.  Were there additional
instances?

Re: Did we have ^/clients?

[Karl Fogel]

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 Subversion history, maybe the move
>happened back when we were still using CVS.  (I don't believe we
>preserved our CVS history when we started self-hosting, because cvs2svn
>was a difficult and not-yet-solved problem.)

That's correct, but I'm pretty sure this was in SVN and post-dated our
move out of CVS (which happened in 2001, after all).

-Karl

Re: Did we have ^/clients?

[Karl Fogel]

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 tree
>anywhere in its history[1], and Bert's mirror of the svn.collab.net
>repository doesn't have an ^/clients tree either.
>
>So...
>
>Did a ^/clients directory exist?  If yes, where is its history?

As I told Daniel in IRC, my memory is both a sieve and a holodeck, so I
could be very wrong.  But I do recall that we had "/clients" at one
point, for clients that we didn't officially support but wanted to give
version control space to, or something like that.  Sound familiar?

-Karl

Re: Did we have ^/clients?

[Daniel Shahaf]

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 corresponding ASF revision is an empty padding revision:
http://people.apache.org/~danielsh/svnrev?r5945

Re: Did we have ^/clients?

[Hyrum K Wright]

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 recalls it having existed.
>
> I remember svn (the command) living under subversion/clients/svn and
> being moved to subversion/svn.
>
> If there's no evidence of this in our Subversion history, maybe the move
> happened back when we were still using CVS.  (I don't believe we
> preserved our CVS history when we started self-hosting, because cvs2svn
> was a difficult and not-yet-solved problem.)

But Mike did stitch the CVS history to the existing SVN history when
he prepared the dumpfile for the migration to the ASF repo.

-Hyrum


-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

Re: Did we have ^/clients?

[Greg Hudson]

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) living under subversion/clients/svn and
being moved to subversion/svn.

If there's no evidence of this in our Subversion history, maybe the move
happened back when we were still using CVS.  (I don't believe we
preserved our CVS history when we started self-hosting, because cvs2svn
was a difficult and not-yet-solved problem.)

Did we have ^/clients?

[Daniel Shahaf]

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], and Bert's mirror of the svn.collab.net
repository doesn't have an ^/clients tree either.

So...

Did a ^/clients directory exist?  If yes, where is its history?

Daniel


[1] as determined by by "grep -ar subversion/clients db/revs/8[3456789][0-9]* | 
grep -Eav '/(trunk|tags|branches)/'".

RE: Problems compiling 1.7.0 on redhat el4 64bit

[michael_rytting]

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 bit 
redhat systems.  So from our perspective this issue is closed.

-Original Message-
From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] 
Sent: Tuesday, August 16, 2011 10:56 AM
To: Mark Phippard
Cc: dev@subversion.apache.org; philip.mar...@wandisco.com; RYTTING,MICHAEL 
(A-ColSprings,ex1)
Subject: 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 mentioned before, we saw this same problem in the Linux RPM's that 
> we provide.  Currently we are working around it by doing the build on 
> RHEL 5 and dropping support for RHEL 4, but obviously the preferred 
> solution for us would be to continue to support RHEL 4.

I don't think we should revert this change, as it's a symptom of a compiler 
bug.  If my understanding of this thread is correct, you could just disable 
optimizations for your RHEL 4 builds, and things should work, no?

-Hyrum

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

JavaHL Bug: cannot propedit versioned props by URL

[Mark Phippard]

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 revision

We want to use this API in Subclipse to freeze svn:externals properties in a
tag after committing it.  TortoiseSVN seems to offer to do this now.


-- 
Thanks

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

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Hyrum K Wright]

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 mentioned before, we saw this same problem in the Linux RPM's that we
> provide.  Currently we are working around it by doing the build on RHEL 5
> and dropping support for RHEL 4, but obviously the preferred solution for us
> would be to continue to support RHEL 4.

I don't think we should revert this change, as it's a symptom of a
compiler bug.  If my understanding of this thread is correct, you
could just disable optimizations for your RHEL 4 builds, and things
should work, no?

-Hyrum

-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/

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

[Peter Samuelson]

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

I found sprintf inside sprintf to be quite confusing, so I changed it
to sprintf inside strcat, in r1158343.  strcat seemed appropriate
anyway, even without the confusing nesting issue.  Hope nobody minds.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Branko Čibej]

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 compiling  with -fno-strict-aliasing? What we're seeing
here is clearly a compiler bug, and GCC did have trouble with strict
aliasing bugs at some point.

-- Brane

Re: Problems compiling 1.7.0 on redhat el4 64bit

[Mark Phippard]

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 we
provide.  Currently we are working around it by doing the build on RHEL 5
and dropping support for RHEL 4, but obviously the preferred solution for us
would be to continue to support RHEL 4.

Mark




On Wed, Aug 10, 2011 at 3:52 PM,  wrote:

> I am attaching a stack trace with symbols enabled.
>
> I'm using gcc.  The default in the makefile.
>
> I am using the apr that you get from the get-deps.sh script.
> APR_HAS_THREADS is defined.
>
> If I disable optimizations by doing "make CFLAGS=-O0" the program no longer
> crashes.
>
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: Tuesday, August 09, 2011 3:34 PM
> To: Mark Phippard
> Cc: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development;
> us...@subversion.apache.org
> Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
>
> Mark Phippard  writes:
>
> > On Tue, Aug 9, 2011 at 4:49 PM,  wrote:
> >
> >> ** **
> >>
> >> Ok, I’ve tracked down which revision caused the problem.  It happened
> >> in rev 1104160.  Stefan2 made a change to utf.c to speed up UTF8
> conversion.
> >> Ever since this change went in I am seeing subversion crash when I
> >> compile on 64bit el4.
> >>
> >> ** **
> >>
> >> Just for kicks and giggles I updated to the HEAD revision of
> >> http://svn.apache.org/repos/asf/subversion/trunk.  Did a reverse
> >> merge on rev 1104160, cleaned up the conflicts and built it and
> >> viola!  No more crashing when built on 64bit el4.
> >>
> >
> > Thanks.  Moving the thread to dev@
> >
> > Can someone look at this and possibly fix it?
> >
> > If you are not on users@, and to summarize this thread.  SVN builds
> > fine on RHEL 4 64-bit but crashes immediately on any command, even svn
> > help.  I saw the same problem with our builds.
>
> It could be a compiler/optimiser bug.  Which compiler are you using?
> Can you provide a stack trace of the crash (with debug symbols please)?
> Does the crash go away if you compile utf.c without optimisation?  Which
> version of APR are you using?  Is APR_HAS_THREADS defined in apr.h?
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>



-- 
Thanks

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

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

[Daniel Shahaf]

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
> 
>   Status|NEW   |RESOLVED
> 
>   Resolution|  |FIXED
> 
> Target milestone|1.7-consider  |1.7.0
> 
> 
> 
> 
> 
> --- Additional comments from danie...@tigris.org Tue Aug 16 07:25:44 
> -0700 2011 ---
> Marking FIXED; reopen if you disagree.

Just to clarify: if someone wants to reopen this, I'll view this as an
instance of ordinary routing (like the "Revert changes that break my
build" policy).  The reason I'm marking this FIXED now --- rather than
wait a day, see no objections, and mark it FIXED then --- is that the
second way means I have to add an entry to my TODO list...

Re: private functions in public api?

[Neels J Hofmeyr]

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 changed??
> 
> Such functions are unsupported even though they appear in a public
> header.  Oh, I see in
> 
>  we say that was the practice 'pre-Subversion 1.5' and not current practice.  
> A few such symbols have been introduced in each (minor) release.  The ones 
> you pointed out here are ones I made private in the recent API review.  Since 
> they are closely related to other functions that are public, it seemed to 
> make sense to leave them there at the time I made them private, along with 
> being less churn, as I wasn't sure whether they'd survive till 1.7.0 at all 
> (but now they have).
> 
> I can move these into a private header if it's helpful.  Should I?

I'd personally find it helpful if I were a developer using SVN's API --
because I'd just think I can use all the functions that are there. (Then two
years later I'd read that '__' means 'not long term supported' and then I'd
understand why my code stopped working. -- "gah, why didn't they put it in a
*private* header if it's private!?")

But I don't have a concrete real case, so
+0

~Neels

> 
> (As a separate question, does anyone know whether the reasons are 'soft'
> such as tidiness or 'hard'?  I seem to recall a discussion in the
> distant past concerning a problem with symbols being exported into DLLs
> and becoming part of the ABI, but I don't recall the exact problem or
> the conclusion.)
> 
> - Julian
> 
> 
>> [[[
>>> svn cat $svnrepos/tags/1.7.0-beta3/subversion/include/svn_dirent_uri.h |
>> grep [a-z]__[a-z]
>>  *- @c svn_relpath__internal_style()
>> svn_relpath__internal_style(const char *relpath,
>> svn_uri__is_child(const char *parent_uri,
>> svn_relpath__is_child(const char *parent_relpath,
>> svn_relpath__is_ancestor(const char *parent_relpath,
>> svn_uri__is_ancestor(const char *parent_uri,
>> ]]]
>>
>> ~Neels
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: Ctypes-python Array class self-reference problem

[Daniel Shahaf]

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: abstract class
.



Julian Foad wrote on Mon, Aug 15, 2011 at 17:39:55 +0100:
> For anyone interested: I'm trying to debug a memory problem in the
> ctypes-python bindings Array class which models an apr_array_header_t
> array.  I suppose this class may never have worked properly, as it gets
> exercised very little within the bindings and had no unit test cases
> until today.
> 
> Running within its test suite it mostly works, but there appears to be a
> problem in making a deep copy of, or holding onto a reference to, each
> element when a new array is initialized.
> 
> A simple demonstration in the Python interpreter:
> 
> $ (cd subversion/bindings/ctypes-python/ && python -i
> test/setup_path.py)
> >>> from csvn.core import *
> >>> from csvn.types import Array
> >>> a1 = Array(c_char_p, ['one'])
> >>> a1
> Array(['Array('])
> 
> The last line should have shown "Array(['one'])", but it printed garbage
> from the Python interpreter's memory.  This is so bad that I wonder if
> my expectations are wrong.
> 
> The attached patch contains various changes and additions that I tried
> unsuccessfully, and it adds tests that all pass (for me) except for the
> places where they extend an Array with another (or the same) array.
> Initially I thought the problem was only with self-referencing, because
> I saw the failures in expressions such as "a1.extend(a1)", but now I am
> noticing the same effect more widely.
> 
> Any hints appreciated.
> 
> - Julian
>