Re: "Missing Date and Author in Svn Log" ralate to db folder hard link reference count ?
Ben Reser writes: > On 3/17/14, 9:12 PM, Steven Wang wrote: >> My Subversion server install on Centos, running as svnserve. >> >> I have follows repositories created on server : >> I use “svnadmin create” to create repository, >> some hard link reference count for db folder is 6 >> >> (drwxrwsr-x 6 stevenw stevenw 4096 Mar 14 10:00 db) >> >> And some is 7. >> >> (drwxrwsr-x 7 stevenw stevenw 4096 Nov 22 11:08 db) >> >> If hard link reference count is 7 woks ok. >> But if the count is 6, Date, Author and log message all missing! >> >> Could you please help to tell why and how to fix. > > db is a directory so that field is not the hard link reference count but > rather > the number of direct children of the directory (an empty directory will always > have 2 because of the '.' and '..' entries). > > Based on what you're saying I'd imagine that you're missing the db/revprops > directory in your repository. > > The only fix would be to recover this data from a backup. A new repository has a count of 6 so it's not clear that any of the repositories are corrupt, it looks as if the repositories with 7 have an extra subdir inside db/. How are you accessing Date/Author/Log? You mention svnserve, if you are using the svn:// protocol and have authz configured then authz may deny access to the Date/Author/Log. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: "Missing Date and Author in Svn Log" ralate to db folder hard link reference count ?
On 3/17/14, 9:12 PM, Steven Wang wrote: > My Subversion server install on Centos, running as svnserve. > > I have follows repositories created on server : > I use “svnadmin create” to create repository, > some hard link reference count for db folder is 6 > > (drwxrwsr-x 6 stevenw stevenw 4096 Mar 14 10:00 db) > > And some is 7. > > (drwxrwsr-x 7 stevenw stevenw 4096 Nov 22 11:08 db) > > If hard link reference count is 7 woks ok. > But if the count is 6, Date, Author and log message all missing! > > Could you please help to tell why and how to fix. db is a directory so that field is not the hard link reference count but rather the number of direct children of the directory (an empty directory will always have 2 because of the '.' and '..' entries). Based on what you're saying I'd imagine that you're missing the db/revprops directory in your repository. The only fix would be to recover this data from a backup.
Re: svnserve 1.8 + slow network + large svn:mergeinfo property
"Matthews, David" writes: > 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. It's proposed for the next 1.8.x release. The fix for 1.8 is http://svn.apache.org/viewvc?view=revision&revision=r1578885 if you want to build your own binary. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
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" 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: svnserve 1.8 + slow network + large svn:mergeinfo property
"Matthews, David" 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 Martin | Subversion Committer WANdisco // *Non-Stop Data*
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
EXTERNALS remote status not reported
Hi,
For the following working copy structure:
- working_copy_root_dir
-- externalFileNORMAL(node status = normal)
-- externalFileMISSING (node status = missing)
-- externalFileOBSTRUCTED(node status = obstructed)
if I run:
cd working_copy_root_dir
svn status -u .
then, the out-of-date sign ('*') of the EXTERNAL files is not presented
(like using "--ignore-externals" option, but I'm not), although I
committed file content changes for the files to which those EXTERNALs
point, from another working copy.
Is this an intended behavior?! I tested with:
svn, version 1.8.5 (r1542147)
compiled Nov 27 2013, 04:10:18 on x86_64/x86-microsoft-windows5.1.2600
This behavior is consistent on both Windows and Linux.
Thanks,
Florin Avram
Re: Subversion checked-out files not indexed in Windows search
On 17.03.2014 17:29, Pete wrote: > Ivan Zhakov visualsvn.com> writes: > >> On 10 March 2014 18:25, Gareth McCaughan >> lightblueoptics.com> wrote: >>> It appears that files checked out using Subversion (1.7 onwards) >>> are marked as not indexable by Windows search. The way in which >>> this happens appears to be as follows: > Wouldn't it be the easiest way to copy the temporary file (in such a case > it gets the default attributes and ACLs of the destination folder) and > after that erase the original temporary file? Easiest, yes. Correct, no. Copying a file is not atomic; renaming is, and we depend on the atomic behaviour of rename to keep working copies consistent. That's ignoring the fact that a rename usually takes the same amount of time regardless of the size of the file, whereas copy does not. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
