"svn pget svn:externals -r . -R" dramatically slow

2017-05-16 Thread Andry
Hello Users, Original issue: https://issues.apache.org/jira/browse/SVN-4681 Just discovered a really strange case where exactly titled command bring really slow response. The repository contains more than 1000 revisions. The WC is in the middle, say at rev 1193 (the current), the show log

Re: Error running make for subversion

2017-05-16 Thread Daniel Shahaf
Joseph, Anselm wrote on Tue, May 16, 2017 at 21:04:57 +: > chmod: /opt/eai/ci/subversion-1.9.5/svn/libexec/mod_dav_svn.so: A file or > directory in the path name does not exist. > apxs:Error: Command failed with rc=65536 Note that if you use svn:// or svn+ssh://, you don't need mod_dav_svn

RE: Error running make for subversion

2017-05-16 Thread Joseph, Anselm
I set LDFLAGS and it got rid of the libexpat warnings. Still getting the same error with 'make install' though. Any guidance is appreciated. Thank you. /opt/eai/ci/subversion/build/install-she -c -m 644 ./subversion/svnversion/svnversion.1

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread Branko Čibej
On 16.05.2017 21:28, Stefan Sperling wrote: > On Tue, May 16, 2017 at 12:02:38PM -0700, lumi wrote: >> Isn't it a mistake in method of getting file size on deduplicated volume? > Subversion asks APR (a portability library) for the filesize. > APR does something to find that size. Subversion uses

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread Stefan Sperling
On Tue, May 16, 2017 at 12:02:38PM -0700, lumi wrote: > Isn't it a mistake in method of getting file size on deduplicated volume? Subversion asks APR (a portability library) for the filesize. APR does something to find that size. Subversion uses the value reported by APR, and Subversion does not

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread lumi
Isn't it a mistake in method of getting file size on deduplicated volume? What I showed on screenshots is what Windows Explorer says. Other applications shows only one size value, e.g. Powershell Get-ItemProperty gets only actual size, no matter deduplicated volume or not, and this size is always

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread Stefan Sperling
On Tue, May 16, 2017 at 10:57:44AM -0700, lumi wrote: > Size mismatch is definitly takes place. Actual size is normal, but size on > disk is a bit unreal, again because of deduplication. > The whole point of a hotcopy is to have

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread lumi
Size mismatch is definitly takes place. Actual size is normal, but size on disk is a bit unreal, again because of deduplication. -- View this message in context:

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread lumi
NTFS with deduplication enabled (Windows Server 2016). Problem files have APL attributes (Archive, SparseFile, ReparsePoint), which means that file takes part in deduplication I guess. Hotcopy of repository to WebDav network drive gives exactly the same result. It means that problem in source

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread Stefan Sperling
On Tue, May 16, 2017 at 06:21:06AM -0700, lumi wrote: > And so on with each next hotcopy --incremental command. Binary comparison > revision 14, 21, 22 files of original repositary and backup gives equal > result. What reason of this strange behaviour? The only possible reasons are a size

Re: svn hotcopy incremental overwrites existing revisions in backup

2017-05-16 Thread Daniel Shahaf
lumi wrote on Tue, May 16, 2017 at 06:21:06 -0700: > C:\Users\Администратор.WIN-DBM2OE9OJ54>svnadmin hotcopy > D:\Repositories\Sandbox D:\Test --incremental > * Copied revision 14. > * Copied revision 21. > * Copied revision 22. > > C:\Users\Администратор.WIN-DBM2OE9OJ54>svnadmin hotcopy >