Hi everybody,
is there somewhere some documentation about svn performance(CPU/Network) other
than the one at IBM pages?
regards
Thomas
Hello,
How fast would you expect svn checkout to be from a server like one below?
Considering eveyrthing on the server functioning as expected.
Apache 2.2.3
128G mem
10G
FSFS is local storage.
Thanks,
--Roman Naumenko
___
Thi
I run a small team of web developers (6) who all work from an in-house
repository. We make lots of commits and often and notice the performance gets
pretty bad. Sometimes taking as long as 2 minutes to commit a change. We rely a
lot on server-side software so we often need to commit to see what
Is there a way to improve, subversion/apache performance? Can anyone
point me to a documentation where i could improve my setup.
Here's my server specs:
apache-2.2
svn-1.3
sles10 sp3
windows ad for authentication
I'm using svn 1.3 as it was the only one the comes with my os.
Thanks,
West
to this performance issue.
It would be really helpful if someone helps me on this.
Thanks,
Sakshi
Hi,
I am working on a tool to establish performance benchmarks for
Subversion. Primary goal would be to have some controlled tests for
doing release to release comparison. The immediate goal is to come up
with something to compare the performance of current release with the
development going on
age.
I don't see how this can be answered. There are too many variables to
consider. I/O performance, revision history of the items you're
checking out, how much data you're checking out, server CPU and I/O
performance on the client end all come to mind.
Do you have a specific performance concern?
On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
Hello,
How fast would you expect svn checkout to be from a server like one
below? Considering eveyrthing on the server functioning as expected.
Our bottleneck is usually the CPU, but we're doing svn+ssh access. So I
lean towards a few less but mo
>
>> Apache 2.2.3
>>
>> 128G mem
>> 10G
>> FSFS is local storage.
> I don't see how this can be answered. There are too many variables to
> consider. I/O performance, revision history of the items you're
> checking out, how much data you're che
On 2013/07/08 2:06 PM, Thomas Harold wrote:
> On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
>> Hello,
>>
>> How fast would you expect svn checkout to be from a server like one
>> below? Considering eveyrthing on the server functioning as expected.
>>
> Our bottleneck is usually the CPU, but we're do
On Mon, Jul 8, 2013 at 2:18 PM, Naumenko, Roman
wrote:
> On 2013/07/08 2:06 PM, Thomas Harold wrote:
>> On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
>>> Hello,
>>>
>>> How fast would you expect svn checkout to be from a server like one
>>> below? Considering eveyrthing on the server functioning as
>>> Considering eveyrthing on the server functioning as expected.
>>>
>>> Apache 2.2.3
>>>
>>> 128G mem
>>> 10G
>>> FSFS is local storage.
>> I don't see how this can be answered. There are too many variables to
>>
(with average speed 2MB/s).
>
> Is it considered good, bad or total disaster in term of svn performance?
I'd generally expect checkout performance to be limited by the
disk/filesystem speed of the client, especially since it has to also
write the hidden pristine copy. So a faster server may
ow fast would you expect svn checkout to be from a server like one below?
>>>> Considering eveyrthing on the server functioning as expected.
>>>>
>>>> Apache 2.2.3
>>>>
>>>> 128G mem
>>>> 10G
>>>> FSFS is local
2.2.3
>>>>>
>>>>> 128G mem
>>>>> 10G
>>>>> FSFS is local storage.
>>>> I don't see how this can be answered. There are too many variables to
>>>> consider. I/O performance, revision history of the items you
On Mon, 08 Jul 2013 14:33:03 +, Andy Levy wrote:
> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>
> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).
9550 Files, half a GB wc size, 15 seconds.
You may want to use another file system?
On Mon, 08 Jul 2013 18:06:45 +, Naumenko, Roman wrote:
...
> For example, on one of the other servers it takes 12-13 min to checkout
> repo with ~17000 files, total size 1.2G (with average speed 2MB/s).
>
> Is it considered good, bad or total disaster in term of svn performance?
t mention little details
like an SSD for the working copy etc. Of course only because those
would have only little impact on checkout performance... ;-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-S
h it's server etc. I
> vote for the latter and claim that you didn't mention little details
> like an SSD for the working copy etc. Of course only because those
> would have only little impact on checkout performance... ;-)
No, that is an admittedly beefy machine with rotating rus
Guten Tag Andreas Krey,
am Dienstag, 9. Juli 2013 um 11:02 schrieben Sie:
> the machine now under my desk
> writes a tree of 10 files and 7GB in about a minute (that is
> not an svn checkout).
And that's the hardware I wanted to read about, there surely is some
advanced RAID or SSD used and n
On Tue, Jul 9, 2013 at 1:31 AM, Andreas Krey wrote:
> On Mon, 08 Jul 2013 14:33:03 +, Andy Levy wrote:
>
>> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>>
>> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).
>
> 9550 Files, half a GB wc
"Naumenko, Roman" writes:
> That box has more than enough CPUs (forty), cores are barely utilized.
Subversion's default cache configuration is very conservative.
Increasing the cache size can reduce disk IO and improve performance:
http://subversion.apache.org/docs/rele
On 2013/07/10 9:41 AM, Philip Martin wrote:
> "Naumenko, Roman" writes:
>> That box has more than enough CPUs (forty), cores are barely utilized.
> Subversion's default cache configuration is very conservative.
> Increasing the cache size can reduce disk IO and
t;> Increasing the cache size can reduce disk IO and improve performance:
>>
>> http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning
>
> That's one of the options I was looking at. When I checked mem
> allocation on the server, it appeared t
Hello Team,
We are using subversion 1.7 which is hosted in linux and apache is being
used along with this.
The linux is very powerful but we are facing a major issue during the
SVN operation from the windows system.
Windows system : Microsoft windows XP
2.85 GB of Ram
tortoisesvn 1.7
Windows
> Hello Team,
>
> We are using subversion 1.7 which is hosted in linux and apache is
> being used along with this.
>
> The linux is very powerful but we are facing a major issue during the
> SVN operation from the windows system.
>
> Windows system : Microsoft windows XP
> 2.85 GB of Ram
> to
On Wed, May 5, 2010 at 09:21, Brendan Farr-Gaynor
wrote:
> I run a small team of web developers (6) who all work from an in-house
> repository. We make lots of commits and often and notice the performance gets
> pretty bad. Sometimes taking as long as 2 minutes to commit a change. We
l team of web developers (6) who all work from an in-house
>> repository. We make lots of commits and often and notice the performance
>> gets pretty bad. Sometimes taking as long as 2 minutes to commit a change.
>> We rely a lot on server-side software so we often need to commit
gs don't compete for head position.
Most OS's will use added RAM for filesystem cache and speed things up
indirectly by avoiding the need to seek for repeated reads. There are
also some subtle things that can slow performance like having apache set
to log client hostnames and a DNS ser
On Wed, May 5, 2010 at 9:21 AM, Brendan Farr-Gaynor
wrote:
> I run a small team of web developers (6) who all work from an in-house
> repository.
> We make lots of commits and often and notice the performance gets pretty bad.
> Sometimes taking as long as 2 minutes to commit a chang
On 5/5/2010 10:25 AM, David Weintraub wrote:
* Don't store binary files in Subversion -- especially big ones that
change a lot. Use a Release Repository or a Build Server to store
binaries. We use Nexus and Hudson.
Side question on this topic: do you have a generic way to map the
binaries gen
> only have one drive, it would help to put the repository on a different one
> so the apache logs don't compete for head position. Most OS's will use added
> RAM for filesystem cache and speed things up indirectly by avoiding the need
> to seek for repeated reads. There
I agree with the general advice already given in this thread: you
should first try to find out where the bottleneck is.
- It can be client-side (e.g. before even sending the commit the
working copy will be locked. This can be very slow with big working
copies (lots of directories), especially on Wi
Hi Brendan,
On Wed, May 05, 2010 at 09:21:43AM -0400, Brendan Farr-Gaynor wrote:
> I run a small team of web developers (6) who all work from an in-house
> repository. We make lots of commits and often and notice the
> performance gets pretty bad. Sometimes taking as long as 2 m
Hi Brendan,
On Wed, May 05, 2010 at 09:46:10AM -0400, Brendan Farr-Gaynor wrote:
> Thanks for your response! Running local copies of the environment
> doesn't seem practical in this case, my guys are working on 10+
> projects at a time all of which can be in different states and which
> need many
On Sat, Jun 26, 2010 at 9:56 PM, west alto wrote:
> Is there a way to improve, subversion/apache performance? Can anyone
> point me to a documentation where i could improve my setup.
>
> Here's my server specs:
> apache-2.2
> svn-1.3
> sles10 sp3
> windows ad for aut
t; to
cleanly rebuild the repo? Is it Berkely DB based (gack!!!)?
>
>
>
> While the other repositories hosted on same box and with the same data size
> are working fine.
>
>
>
> I tried a lot but could not zero down to this performance issue.
>
>
>
> It would be really helpfu
ng fine.
>
> I tried a lot but could not zero down to this performance issue.
>
> It would be really helpful if someone helps me on this.
>
> Thanks,
> Sakshi
>
On Mon, 01 Aug 2011 07:39:59 +, Les Mikesell wrote:
...
> SQLlite has years of development and a good reputation for robust behavior.
I don't doubt that.
> I'd expect it to be hard to match its performance and reliability without
> an equally long development cycle.
W
would like to load and lock objects and files through Toad.
We have configured toad so that it works with version control, the
plugin used is 'Pushok SvnScc'.
The biggest problem we are facing now is the complete lack of
performance.
It takes 5 minutes to check out a file, 5
Guten Tag Somashekarappa, Anup (CWM-NR),
am Donnerstag, 1. August 2013 um 13:51 schrieben Sie:
> May i know where is the bottleneck?
Did you have a look at the CPU and I/O for storage and network on both
client and server? Even Windows provides enough tools built-in to see
if those resources are
> Hello Team,
> We are using subversion 1.7 which is hosted in linux and apache is being used
> along with this.
> The linux is very powerful but we are facing a major issue during the SVN
> operation from the windows system.
> Windows system : Microsoft windows XP
> 2.85 GB of Ram
> tortoisesvn 1.
performance -URGENT
> Hello Team,
> We are using subversion 1.7 which is hosted in linux and apache is
> being used along with this.
> The linux is very powerful but we are facing a major issue during the
> SVN operation from the windows system.
> Windows system : Microsoft windo
> I tried in the same server where svn is hosted but there also it is
> taking too much of time I e it is taking 110 mins to checkout the
> 2200 Mbytes of data(in Windows it took 143 mins).
How many files are in the working copy? For example, millions of small
files can take a significant amoun
Bob Archer wrote on 08/01/2013 09:02:32 AM:
> > We are using subversion 1.7 which is hosted in linux and apache
isbeing used
> > along with this.
> > The linux is very powerful but we are facing a major issue during the
SVN
> > operation from the windows system.
> > Windows system : Microsoft wi
Please stop top posting.
> I tried in the same server where svn is hosted but there also it is taking too
> much of time I e it is taking 110 mins to checkout the 2200 Mbytes of data(in
> Windows it took 143 mins).
>
> I have not tried the command line option.Could you please tell how to do it
>
01 August 2013 15:20
To: Bob Archer
Cc: Somashekarappa, Anup (CWM-NR); users@subversion.apache.org
Subject: RE: SVN performance -URGENT
Bob Archer wrote on 08/01/2013 09:02:32 AM:
> > We are using subversion 1.7 which is hosted in linux and apache
isbeing used
> > along with this.
On 1 Aug 2013 16:52, "Somashekarappa, Anup (CWM-NR)" <
anup.somashekara...@rbc.com> wrote:
>
> Bandwidth is 35.4 MBytes/sec from my system(London) to server(New york)
when i checked with iperf tool.
>
>
> We are using LDAP
>
> AuthzLDAPAuthoritative off
> AuthType Basic
> AuthBasicProvider ldap
>
To: Bob Archer
> Cc: Somashekarappa, Anup (CWM-NR); users@subversion.apache.org
> Subject: RE: SVN performance -URGENT
> Bob Archer wrote on 08/01/2013 09:02:32 AM:
> > > We are using subversion 1.7 which is hosted in linux and apache
> > > isbeing used along with this.
> >
things like how busy the disks are, how busy the CPU cores
are and the network throughput. This will give you an idea of how hard
the Linux server is working while sending out the data to the SVN client.
For the windows client, you will need to look at the Performance Monitor
(perfmon) and
On Aug 1, 2013, at 09:26, Bob Archer wrote:
> The working copy is generally 2x the size of the files in it, since the .svn
> folder contains the pristine copies of your working copy. This is how svn can
> do diffs against changed items In your working copy without hitting the
> server, and als
On Thu, Aug 1, 2013 at 10:18 AM, Somashekarappa, Anup (CWM-NR)
wrote:
>
>
> Hello Bob,
>
> Thanks for your response.
>
> I tried in the same server where svn is hosted but there also it is taking
> too much of time I e it is taking 110 mins to checkout the 2200 Mbytes of
> data(in Windows it too
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
2 and pwauth for validation --
we have other resources and prefer using the same authentication for all for
simplicity.
It "works" but the performance makes it nearly unusable. Monitoring the server
using the top linux utility indicates many, many invocations of "pwauth" for a
s
Hi,
I am suprised by poor performance of svnserve and not sure how can I improve
it.
Test case
I am on a Windows 10 laptop with i7 and SSD. (tested on Windows server too
with similar performance)
I am running both server and client on the laptop - so it doesn't go through
the ne
Hello,
I would like to know how tags and branches are "cheap copy" in terms
of time and space.
Since we can't reorganize the layout, we will need to tag big
directories (about 500 Mb) even if we just sparse-chechkout single
files.
This operation might be done up to 10 times per day.
Is this opera
On Tue, Aug 09, 2011 at 11:06:43AM +0200, Andreas Krey wrote:
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
> small 'second consecutive commit fails' test script with that. It's
> not the local operations, but those that act on the repository (here:
> file:///...) that take r
Hi Andreas,
On Tue, Aug 9, 2011 at 11:06 AM, Andreas Krey wrote:
> On Mon, 01 Aug 2011 07:39:59 +, Les Mikesell wrote:
> ...
> > SQLlite has years of development and a good reputation for robust
> behavior.
>
> I don't doubt that.
>
> > I'd expect it
On Tue, 09 Aug 2011 11:38:41 +, Stefan Sperling wrote:
...
> Which script are you referring to? Can you post it or provide a link?
This one:
set -xe
rm -rf repo wc
time svnadmin create repo
time svn checkout file:///`pwd`/repo wc
cd wc
mkdir D
touch A D/B D/C E
# svn add . # <- That nuisance
On Tue, Aug 09, 2011 at 11:46:06AM +0200, Erik Huelsmann wrote:
> The fact that the 'svn up' takes about a second can't be blamed on SQL Lite
> or any other SQL engine. The Subversion client sleeps 1 second to make sure
> that it's able to detect changes to files: it does timestamp checks and
> ret
On Tue, 09 Aug 2011 12:12:17 +, Stefan Sperling wrote:
...
> export SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS=1
ITYM "...AMPS=yes". Then it's running faster (and not apparently corrupt)
indeed, and we're now closing up to git.
I'd like SVN_DO_CONTENT_CHECK_ON_EQUAL_T
Hi, Andreas,
Andreas Krey [mailto:a.k...@gmx.de]
> But I may be barking up the wrong tree. I built svn 1.7 and ran my
small
> 'second consecutive commit fails' test script with that. It's not the
> local operations, but those that act on the repository (here:
> file:///...) that take ridiculously
lem we are facing now is the complete lack of performance.
>
> It takes 5 minutes to check out a file, 5 minutes to check in.
>
> Anybody any idea ? If we check out the option ‘version control’ in Toad, the
> performance of loading the object is ok
>
> Is there a problem
slowing you down.
Steve
>
> From: Stephen Butler [mailto:sbut...@elego.de]
> Sent: maandag 7 mei 2012 17:20
> To: Piet Arickx
> Cc: users@subversion.apache.org
> Subject: Re: Toad - performance problems Subversion
>
>
> On May 7, 2012, at 15:54 , Piet Arickx wrote
On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
That box has more than enough CPUs (forty), cores are barely utilized.
How is the access over ssh can be configured? I thought it's only
http(s) or svn proto.
http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls
http:/
On 2013/07/08 5:10 PM, Thomas Harold wrote:
> On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
>>
>> That box has more than enough CPUs (forty), cores are barely utilized.
>> How is the access over ssh can be configured? I thought it's only
>> http(s) or svn proto.
> http://svnbook.red-bean.com/en/1.7/s
On our setup (10k RPM SAS RAID-10 across 6 spindles, AMD Opteron 4180
2.6GHz), we're finding that "svnadmin verify" is CPU-bound and only uses
a single CPU core.
Is it possible that "svnadmin verify" could be multi-process in the
future to spread the work over more cores? Or is that technical
commits are very slow compared to local disk access. Are there
> any samba server settings that would be likely to help with the speed?
The new-in-1.8 exclusive-locking option in ~/.subversion/config
can help performance on network filesystems (see below).
I would recommend against usi
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
Hi all,
I've just finished a dump/load cycle on about 500GB worth of repositories to
bring in the more efficient changes for FSFS in 1.8 (We're on 1.8.8 now). I'm
looking at utilising some performance tweaks to make the most of the hardware
the server is running on. Could so
av using apache2 and pwauth for validation
> -- we have other resources and prefer using the same authentication for all
> for simplicity.
>
> It "works" but the performance makes it nearly unusable. Monitoring the
> server using the top linux utility indicates many,
"Weatherby,Gerard" writes:
> It "works" but the performance makes it nearly unusable. Monitoring
> the server using the top linux utility indicates many, many
> invocations of "pwauth" for a single client request. The next thing I
> was going to try w
Jakub Petr wrote on Thu, Dec 22, 2016 at 10:28:24 +0100:
> Why the "transmitting phase" should take so long?
Usually it's because of virus scanners intercepting the disk operations
(opening/writing files).
What makes you think the slowness is svnserve's fault? Is the commit
faster over file:// t
es).
>
> What makes you think the slowness is svnserve's fault? Is the commit
> faster over file:// than over svn://localhost?
There is more that can be tried to reduce I/O and to check
whether there it results in improved performance:
* use 'svn import' instead of add/comm
performance of SVN operations affected (i.e. update, switch, checkout,
etc.)?
Thanks.
KJQ
Guten Tag San Martino,
am Donnerstag, 11. November 2010 um 11:16 schrieben Sie:
> Since we can't reorganize the layout, we will need to tag big
> directories (about 500 Mb) even if we just sparse-chechkout single
> files.
> This operation might be done up to 10 times per day.
> Is this operation r
On 11/11/10 5:57 AM, Thorsten Schöning wrote:
Guten Tag San Martino,
am Donnerstag, 11. November 2010 um 11:16 schrieben Sie:
Since we can't reorganize the layout, we will need to tag big
directories (about 500 Mb) even if we just sparse-chechkout single
files.
This operation might be done up t
On 11/11/10 4:16 AM, San Martino wrote:
Hello,
I would like to know how tags and branches are "cheap copy" in terms
of time and space.
Since we can't reorganize the layout, we will need to tag big
directories (about 500 Mb) even if we just sparse-chechkout single
files.
This operation might be
> I would like to know how tags and branches are "cheap copy" in terms
> of time and space.
>
> Since we can't reorganize the layout, we will need to tag big
> directories (about 500 Mb) even if we just sparse-chechkout single
> files.
> This operation might be done up to 10 times per day.
> Is thi
Guten Tag Les Mikesell,
am Donnerstag, 11. November 2010 um 14:37 schrieben Sie:
> Doesn't the client understand the file history if you 'svn switch' to the tag
> path in a working copy and just get the differences, if any?
OK, maybe I'm wrong, because I don't use svn switch but always use
comple
s at the same time, if neccessary. In
> this case every other developer would have large updates with each new
> tag.
I sometimes need multiple working copies of the same URL, so I couldn't do
that. Further, and that's IMHO more important in the context of performance,
I don't
On 11/11/2010 8:48 AM, Thorsten Schöning wrote:
Guten Tag Les Mikesell,
am Donnerstag, 11. November 2010 um 14:37 schrieben Sie:
Doesn't the client understand the file history if you 'svn switch' to the tag
path in a working copy and just get the differences, if any?
OK, maybe I'm wrong, beca
2010/11/11 Les Mikesell :
> That's not wrong in the sense that it won't work for a small repository, but
> it is not an efficient way to use subversion where you are concerned about
> space or time usage on the client. Normally you would just check out
> workspaces of one or more locations where y
Hi San,
On Fri, Nov 12, 2010 at 2:57 PM, San Martino wrote:
> 2010/11/11 Les Mikesell :
>> That's not wrong in the sense that it won't work for a small repository, but
>> it is not an efficient way to use subversion where you are concerned about
>> space or time usage on the client. Normally you
On 11/12/10 7:57 AM, San Martino wrote:
2010/11/11 Les Mikesell:
That's not wrong in the sense that it won't work for a small repository, but
it is not an efficient way to use subversion where you are concerned about
space or time usage on the client. Normally you would just check out
workspace
2010/11/12 Erik Huelsmann :
>> Do you think Subversion scales well for the following case, where
>> /trunk contains about 5000 files and its size is 500Mb
>> development requires 10 commits per day, 2-3 files changed per commit
>> on average.
>> Each commit is tagged (yes) from /trunk on the reposi
2010/11/12 Les Mikesell :
> On 11/12/10 7:57 AM, San Martino wrote:
>>
>> 2010/11/11 Les Mikesell:
>>>
>>> That's not wrong in the sense that it won't work for a small repository,
>>> but
>>> it is not an efficient way to use subversion where you are concerned
>>> about
>>> space or time usage on t
Hi San,
On Fri, Nov 12, 2010 at 3:20 PM, San Martino wrote:
> 2010/11/12 Erik Huelsmann :
>>> Do you think Subversion scales well for the following case, where
>>> /trunk contains about 5000 files and its size is 500Mb
>>> development requires 10 commits per day, 2-3 files changed per commit
>>>
On Friday 12 November 2010, San Martino wrote:
> Basically we need to test each commit from /tag while others proceed
> on /trunk. Before we used to lock - modify - TEST [- correct bugs]
> unlock. This really slows down the development because TEST is a long
> period while development needs to be v
On 11/12/2010 8:24 AM, San Martino wrote:
To avoid network issues with full checkouts we think about
sparse-checkouts of what is really needed, in most of the cases it's
single files
You can do whatever works best for each client on the client side.
Someone who has good connectivity and works
2010/11/12 Les Mikesell :
> In any case, as I tried to point out earlier and others have repeated, it
> doesn't matter if you copy to tags or not. The purpose of the tag is just
> to give you a human-friendly name that you can use for documentation or
> steps in your process. Even without explici
Dear Sir:
I have a SVN server on windows2003.
Now the developer want check in about 10G date to it, and in the last few
months, they will check in about 100G data.
Will so many data affect on server’s performance？
Best regards
wang.yu [cid:image001.png@01CDA601.066B5D10]
Voip 523-6949
<>
Hi,
this topic was raised several times in the past - the answers range from
"will be better/solved in the next version 1.7" or "it is due to ntfs vs
ext3/4" or it's the AV, network setup or the Windows file indexing
service. After disabling all those and running a test checkout on Linux
and Wind
On 5/14/14, 12:06 PM, Ben Reser wrote:
> Actually I think it's more that you really must have this enabled if you have
> revprop packing turned on. I can't think of a reason you don't want this turn
> off other than desiring to reduce resource usage at the cost of slow
ation module that also looks
at paths this added overhead does nothing for you. LDAP and other external
authentication makes the performance of this worse, however it's still a
measurable performance delay without such systems.
off: The secondary path setting does not run. It presumes if you h
ally must have this enabled if you have
> revprop packing turned on. I can't think of a reason you don't want this
> turn off other than desiring to reduce resource usage at the cost of slower
> performance.
>
> The documentation in question is the release notes:
> http://sub
On 5/15/14, 1:15 AM, Terry Dooher wrote:
> That's so much clearer now and sounds like something I can definitely use.
> As I understand it, the downside is that the server will reveal path
> components
> and filenames within restricted areas during log operations?
Don't think you quite understand
On Fri, May 16, 2014 at 2:05 PM, Ben Reser wrote:
> On 5/15/14, 1:15 AM, Terry Dooher wrote:
> > That's so much clearer now and sounds like something I can definitely
> use.
> > As I understand it, the downside is that the server will reveal path
> components
> > and filenames within restricted a
syncing form the same svn:// source to an local
repository (file://), oberon completes about 400 revisions in the time
it takes colossus to grind through 80.
The BTRFS machine is our build server. Performance with (1.6.x)
working copies is quite acceptable, but I'm glad I'm not using it to
hos
Hi:
Suppose we have two exactly same subversion repository trees, one which
HEAD is at revision 9000 and one which HEAD is only at revision 100. Is the
one with low revision number performs faster? Or should be no difference?
the performance, I mean "svn update", "svn commit" etc.
Thank you.
1 - 100 of 206 matches
Mail list logo
