It used to be much, much worse: see the old thread at
http://subversion.1072662.n5.nabble.com/Poor-performance-for-large-software-repositories-downloading-to-CIFS-shares-td155699.html.
A large improvement occurred for Subversion on CIFS in a following
Subversion release, I believe as a performanc
Hi Bert,
From: Bert Huijben [mailto:b...@qqmail.nl]
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
already?
No,
There is no i
No,
There is no issue for this specific part of those threads created as nobody
was able to produce a reproduction recipe for this problem to the developers
yet.
All the threads you quoted end with this request. So unless you add a way to
reproduce the problem (perhaps with
On Tue, Sep 24, 2013 at 11:43:35AM -0500, Les Mikesell wrote:
> I think this has been discussed here previously but I don't remember
> any definitive conclusions so I'll ask again. We now have some
> Windows users with samba-mounted disk space and large svn checkouts
> and commits are very slow c
I think this has been discussed here previously but I don't remember
any definitive conclusions so I'll ask again. We now have some
Windows users with samba-mounted disk space and large svn checkouts
and commits are very slow compared to local disk access. Are there
any samba server settings th
Hello!
What is going wrong if I get
svn: warning: W120171: Error running context: An error occurred
during SSL communication
five out of six times I try to update a repository or to do some other
subversion command?
(This is Tortoise SVN/64
TortoiseSVN 1.8.2, Build 24708 - 64 Bi
Hello,
There seems to be a problem with the TortoiseSVN1.8.0+, which returns a server
conflict when a new file is attempted to be added. We observed the problem only
when adding files to the server running SVN1.5.5. No problems were observed
when adding files to our second server, running SVN 1
Seumas Soltysik writes:
> I am still a bit confused about the difference between --steal-lock and
> --disable-locking. I understand that --steal-lock basically deletes/steals
> the lock property on revision 0 which controls who has the right to perform
> an svnsync. I use this in the event that a
