Problem with Centos 7 RPMs
I been using the Subversion 1.10 RPMs provided by WANdisco on Centos 7. http://opensource.wandisco.com/centos/7/svn-1.10/RPMS/x86_64/ I have 1.10.6 installed but I can't upgrade to 1.10.7. If I try running "yum update" I get an error with package subversion-python-1.10.7-1.x86_64 (WANdisco-svn): Requires: python >= 3 I'm hoping the maintainers of those RPMs watch this list and can comment. Thanks, David
svn info tree conflicts bug using svn 1.10.6?
I appear to be getting incorrect results reported by "svn info --xml" for a file which has tree conflicts. I'm testing with svn 1.10.6 (and 1.9.12 which doesn't have this problem). The results from "svn info" for the conflicted file appear correct. However, "svn info --xml" reports the wrong information for "source-right" (it appears to repeat the information given for "source-left"?). Further details are given below. Is this a known issue? Is it fixed in the latest release? This is the script I've used to reproduce the problem: #!/bin/bash set -eu svn --version | head -1 TEST_DIR=$(mktemp -d) svnadmin create $TEST_DIR/test-repos REPOS_URL="file://$TEST_DIR/test-repos" svn mkdir -q -m "" $REPOS_URL/trunk svn copy -q -m "" $REPOS_URL/trunk@1 $REPOS_URL/branch1 svn copy -q -m "" $REPOS_URL/trunk@1 $REPOS_URL/branch2 svn checkout -q $REPOS_URL/branch1 $TEST_DIR/wc cd $TEST_DIR/wc echo "Test 1" > file svn add -q file svn commit -q -m "" svn switch -q $REPOS_URL/branch2 echo "Test 2" > file svn add -q file svn commit -q -m "" svn update -q svn merge --non-interactive $REPOS_URL/branch1 echo === svn info file svn info file echo === svn info --xml file svn info --xml file cd $OLDPWD rm -rf $TEST_DIR "svn info file" reports the following: ... Tree conflict: local file obstruction, incoming file add upon merge Source left: (none) ^/trunk/file@1 Source right: (file) ^/branch1/file@5 Using svn 1.10.6, "svn info --xml file" reports the following: ... You can see the information for "source-right" is not correct. It works fine with svn 1.9.12: I've tested with other sorts of tree conflict - they all show the same problem. Thanks, David
svnserve 1.8 + slow network + large svn:mergeinfo property
We recently upgraded from subversion 1.6 to 1.8.5.
After upgrading we have discovered a major performance issue when accessing
some repositories from a remote site.
After much investigation I've discovered that the problem only becomes
obvious for repositories with large svn:mergeinfo properties.
I can reproduce the problem by creating a dummy repository as follows:
#!/bin/bash
svnadmin create test_svn
tempdir=$(mktemp -d)
svn co file://$PWD/test_svn $tempdir
for i in {1..400}; do
svn mkdir --parents $tempdir/trunk/dir-$i
for j in {1..1}; do
echo Test file $j$tempdir/trunk/dir-$i/file-$j
svn add $tempdir/trunk/dir-$i/file-$j
done
done
for i in {1..1000}; do
echo branches/branch-$i:1-2$tempdir/mergeinfo
done
svn ps svn:mergeinfo -F $tempdir/mergeinfo $tempdir/trunk
svn ci -m Setup $tempdir
rm -rf $tempdir
If I vary the number of directories created and the number of lines added
to the svn:mergeinfo property I get the following results doing an ls -R
on the trunk (accessing the repository via svnserve over the slow network
link):
mergeinfo lines: 1000, directories: 100, time: 23s
mergeinfo lines: 1000, directories: 200, time: 46s
mergeinfo lines: 1000, directories: 400, time: 92s
mergeinfo lines: 500, directories: 400, time: 45s
mergeinfo lines: 250, directories: 400, time: 23s
mergeinfo lines: 125, directories: 400, time: 13s
mergeinfo lines: 30, directories: 400, time: 4s
no mergeinfo, directories: 400, time: 3s
The problem only occurs when accessing the repository from the remote site
(relatively slow, busy link). On the local network the command completes
within 1s.
The problem only occurs using svnserve. Accessing the same repository via
http seems OK (mergeinfo lines: 1000, directories: 400, time: 4s)
Increasing the number of files in each directory (e.g. from 1 to 20) makes
virtually no difference to the timings.
info -R commands are affected in a similar way.
As well as 1.8.5, I've tried using 1.8.0 1.8.8 on the server but it made
no difference.
However, using 1.7.9 on the server (accessing using a 1.8.5 client) I get:
mergeinfo lines: 1000, directories: 400, time: 3s
So, this problem seems to have been introduced with 1.8.
The problem doesn't appear to be affected by the client version.
I've tried accessing the repository using an old 1.4.3 client and get the
same performance issue as using a 1.8.5 client.
Does this make sense to anyone?
Why should the size of the svn:mergeinfo property affect ls -R commands?
I haven't managed to measure the network traffic yet but I assume that, for
some reason, svnserve is transmitting a lot of unnecessary information?
Thanks,
David Matthews
RE: svnserve 1.8 + slow network + large svn:mergeinfo property
-Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 18 March 2014 13:02 To: Matthews, David Cc: 'users@subversion.apache.org' Subject: Re: svnserve 1.8 + slow network + large svn:mergeinfo property Matthews, David david.matth...@metoffice.gov.uk writes: Does this make sense to anyone? Why should the size of the svn:mergeinfo property affect ls -R commands? I haven't managed to measure the network traffic yet but I assume that, for some reason, svnserve is transmitting a lot of unnecessary information? Yes. 1.8 introduced optional inherited properties and the server is not properly detecting clients that don't ask for those properties. Running svn ls -R queries a lot of paths and server keeps sending the unwanted inherited properties. Fixed on trunk by r1578853. Philip Many thanks for looking into this so quickly. I guess we'll need to wait for 1.8.9? (we normally use the wandisco RPMs) Unfortunately this is causing us a lot of pain. David Matthews
RE: svnadmin hotcopy losing revprops
-Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 08 November 2013 10:19 To: Matthews, David Cc: subversion_us...@googlegroups.com Subject: Re: svnadmin hotcopy losing revprops dpm david.matth...@metoffice.gov.uk writes: I'm using svn 1.8.4 on RHEL 6.3 (we're in the process of trying to upgrade from svn 1.6 to 1.8). However, the svnadmin hotcopy command doesn't appear to be working correctly with the repositories I've copied over from our 1.6 server - most of the db/revprop directories are missing. I can reproduce this, hotcopy fails to copy some of the revprops corresponding to packed revisions when the repository is 1.7 or earlier format: svnadmin create repo --compatible-version 1.7 perl -i -pe s/1000/10/ repo/db/format for i in `seq 0 75`;do echo $i x.x ; svnmucc -mm put x.x file://`pwd`/repo/f ; done svnadmin pack repo svnadmin hotcopy repo repo2 The bug was introduced to 1.8 by r1520723 and is still present on trunk. Thanks for your response (although it doesn't seem to have made it to the archive yet - perhaps because I used google groups?). It's good to know that the problem is reproducible. I'll go back to using 1.8.3 for the moment. Do you think this bug needs advertising more widely somehow? Our backup procedure relies on hotcopy and, if I hadn't discovered this during my testing, we could have ended up having no useable backups which is a scary thought. Thanks, David Matthews
