Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Fixed in 1.6.14, which will be released in a week.  The CHANGES file in
trunk already contains an appropriate entry :-)

http://svn.apache.org/repos/asf/subversion/trunk/CHANGES

Keith Moore wrote on Fri, Nov 12, 2010 at 15:30:35 +1100:
> 
> > -Original Message-
> > From: Chris Tashjian [mailto:ct...@thepond.com]
> > Sent: Friday, 5 November 2010 11:20
> > To: Daniel Shahaf
> > Cc: users@subversion.apache.org
> > Subject: Re: svnserve.exe (Win32) using 2GB of memory and then crashing?
> > 
> > 
> > > Wrong format file.  Please look at the file 'db/format', not the file
> > 'format'.  Thanks.
> > 
> > 4
> > layout linear
> 
> Did you get a solution to this problem, or are you still looking into it?
> 
> I have a server running svnserve.exe as a windows service and every couple of 
> weeks in runs out of resources.  Not being a server engineer I can't even 
> figure out what resource because I can't log onto the server once it has ran 
> out of resources.
> 
> Please post any solution you come up with.
> 
> Thanks
> Keith.
> #
> Attention:
> The information contained in this message and or attachments is intended
> only for the person or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon,
> this information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the sender and
> delete the material from any system and destroy any copies.
> #

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Daniel Shahaf]

Daniel Shahaf wrote on Fri, Nov 12, 2010 at 10:30:46 +0200:
> Fixed in 1.6.14, which will be released in a week.  The CHANGES file in
> trunk already contains an appropriate entry :-)

Having a CHANGES entry implies that the fix has been backported to the
1.6.x branch already; IOW, you could install ^/subversion/branches/1@head
today instead of waiting for the 1.6.14 release.

Re: svnserve.exe (Win32) using 2GB of memory and then crashing?

[Erik Huelsmann]

On Fri, Nov 12, 2010 at 9:34 AM, Daniel Shahaf  wrote:
> Daniel Shahaf wrote on Fri, Nov 12, 2010 at 10:30:46 +0200:
>> Fixed in 1.6.14, which will be released in a week.  The CHANGES file in
>> trunk already contains an appropriate entry :-)
>
> Having a CHANGES entry implies that the fix has been backported to the
> 1.6.x branch already; IOW, you could install ^/subversion/branches/1@head
> today instead of waiting for the 1.6.14 release.


Except that he'd have to create a Win32 (!) build environment which
almost surely will take him more than a week to get up and running.
I'm sure Slik and the others will catch up really quickly with this
release.

Regards,


Erik.

RE: different problems with merging and mergeinfo

[Brandt, Servatius (External)]

Igor Radic wrote on November 11, 2010 9:48 PM
>
> [...]
> 1. Problem 1 - merging range influences merging results
> It is logical that merging range does NOT influence merging results.
> Meaning, I should get the same results when merging 100 revisions at
> once or 10 times 10 revisions.
> But we have noticed it is not so - in all cases the problem was somehow
> related with a deletion of file/directory.

Please look into issue 3324 which has been solved recently.  If this is
your problem, it will be fixed in one of the upcoming releases.  See:

http://subversion.tigris.org/issues/show_bug.cgi?id=3324

> Usually the difference is only seen in mergeinfo.
> But once we even had very strange case where two branches were created
> and the same range was merged from TRUNK (but in different steps).
> We ended up with 2 exact branches (content and mergeinfo) - at least
> according to Tortoise repo-browser comparison.
> But one branch could be re-integrated into TRUNK, and the other one
> could NOT.
> Are their any known limitations when choosing merging ranges?
> Our current rule is: when choosing merging range, the revision which
> deletes at least one file/folder must be first in the range.
> Does this make sense?

I assume that the two branches were created from the same trunk revision
(otherwise, the mergeinfo would very likely be different).  If the same
merges have been made on both branches, but in finer steps on one of
them, the reintegrate merges to the trunk should work the same way.  If
there was a difference (e.g. you got a tree conflict originating from
the deletion when trying to reintegrate one branch but not when
reintegrating the other one), this might have been caused by the bug
described in issue 3324.

You did not specify what reintegrate problem you encountered.  If the
problem was not in the final merge step but already in the early phase,
when --reintegrate checks the reintegrate source, this could have been
caused by branching off from different trunk revisions.  There is less
chance for these checks to fail in the branch copied from the newer
revision.  But this does not really fit to your description of identical
content and mergeinfo (except you manipulated the latter one).

> 2. Problem 2 - order of actions influences mergeinfo
> I have a very simple example.
> I have TRUNK and two branches (X and Y) created from TRUNK.
> Now the work is finished in both branches and I want to re-integrate
> them back to TRUNK.

So you have merged everything from the trunk up to the HEAD revision
into both branches.

> But in the meantime, one file/folder in branch Y has mergeinfo (although
> it has no mergeinfo in TRUNK).

So Y has some subtree mergeinfo originating from some merge to
a subdirectory or file within Y.

> If I first merge branch X and then branch Y, the same file/folder in
> TRUNK will get mergeinfo - the one as in branch Y (except for TRUNK
> entries, of course), plus the final information about the merge of
> branch Y.

Yes, the subtree mergeinfo of your file/subdirectory is taken over from
Y into the corresponding file/subdirectory in the trunk, supplemented by
the mergeinfo for the reintegrate merge of Y to the trunk you are
performing.  Note that any later merge to the root directory of the
trunk will also change the mergeinfo in that file/subdirectory.

> But if I first merge branch Y and then branch X, the mergeinfo will also
> contain information about merge of branch X.

For the same reason: as any later merge after the merge of Y will update
the subtree mergeinfo, you will also see there information about the
reintegrate merge of X if you reintegrate X later than Y.

> I understand why this happens, but I don't understand why such behaviour
> is wanted.
> I mean, what exactly do I get with this information when it is obvious
> that in branch X this particular mergeinfo was not added/changed?

To understand why this happens: whenever you do some operation that
needs mergeinfo ("svn log -g", "svn blame -g", "svn merge") on
a subdirectory or file within your trunk, it looks for explicit
mergeinfo in that subdirectory/file.  If there is none, it looks up
the parent directory etc.  This causes "svn log -g" to work on
a subdirectory/file that does not have explicit mergeinfo when there is
one on the root directory of your trunk.

But if you now use "svn log -g" on that subdirectory/file within your
trunk that has got some explicit mergeinfo originating from a former
subtree merge to the corresponding subdirectory/file in Y, the search
for explicit mergeinfo on parent directory stops as it already found
this one.  Therefore, this mergeinfo needs to have the complete
information about all merges, also the reintegrate of X done later than
that of Y.

In the above explanation I simplified a bit: Provided that the later
merge of X did not affect that subdirectory/file, the mergeinfo for the
reintegrate merge of X does not have to be propagated to the subtree
mergeinfo, and I think newer 

Re: Question about performance and space

[San Martino]

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 you intend to work and if you
> branch or tag, switch an existing workspace to it (to make changes in a
> branch or build from the tag, which by convention should not have subsequent
> changes).  Just be sure you have committed anything that belongs in the
> current location before the switch. If checkout time is an issue you can
> copy an existing local workspace as the starting point for a subsequent
> switch.


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 repository. How we will
test the tag is a separate issue.
For now also suppose the local wc only contains sparse-checkouts of
single files, not the whole /trunk.
Also suppose that a reorganization of /trunk is not possible.

(concrete tests cannot be done at the moment, I am collecting various
opinions based on user experience on big projects, before doing
simulations)

thanks.

Re: Question about performance and space

[Erik Huelsmann]

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 would just check out
>> workspaces of one or more locations where you intend to work and if you
>> branch or tag, switch an existing workspace to it (to make changes in a
>> branch or build from the tag, which by convention should not have subsequent
>> changes).  Just be sure you have committed anything that belongs in the
>> current location before the switch. If checkout time is an issue you can
>> copy an existing local workspace as the starting point for a subsequent
>> switch.
>
>
> 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 repository. How we will
> test the tag is a separate issue.

Why would you want to tag each commit? A commit is a tag in itself:
there's a unique identifier to refer to the entire commit. This wasn't
the case in PVCS, RCS and CVS, but there's really no reason to tag
each and every commit; if you want to check out what got committed,
just use the revision number!

> For now also suppose the local wc only contains sparse-checkouts of
> single files, not the whole /trunk.
> Also suppose that a reorganization of /trunk is not possible.

Bye,


Erik.

Re: Question about performance and space

[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 the client.  Normally you would just check out
workspaces of one or more locations where you intend to work and if you
branch or tag, switch an existing workspace to it (to make changes in a
branch or build from the tag, which by convention should not have subsequent
changes).  Just be sure you have committed anything that belongs in the
current location before the switch. If checkout time is an issue you can
copy an existing local workspace as the starting point for a subsequent
switch.



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 repository. How we will
test the tag is a separate issue.
For now also suppose the local wc only contains sparse-checkouts of
single files, not the whole /trunk.
Also suppose that a reorganization of /trunk is not possible.

(concrete tests cannot be done at the moment, I am collecting various
opinions based on user experience on big projects, before doing
simulations)


Our repo is about 43 Gb now and has more activity than that.  It contains 
multiple projects some of which probably have more then 5000 files, although not 
in a flat directory. I don't see any scaling issue unless you meant to say 500 
Gb.  However, there may be network issues if your clients do not have good 
connectivity and windows clients may be slow if you do check out the whole mess 
due to their local filesystem.  You might want to make sure that anything you do 
that requires frequent full checkouts is on a machine with good connectivity to 
the server even if you have to provide remote access for people using it.  For 
example, we do automated test builds on virtual machines on the same LAN as the 
subversion server for some of the projects triggered by a Hudson server.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Question about performance and space

[San Martino]

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 repository. How we will
>> test the tag is a separate issue.
>
> Why would you want to tag each commit? A commit is a tag in itself:
> there's a unique identifier to refer to the entire commit. This wasn't
> the case in PVCS, RCS and CVS, but there's really no reason to tag
> each and every commit; if you want to check out what got committed,
> just use the revision number!

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 very frequent. Now with
Subversion we want to profit by concurrent progrommaing and testing.

Re: Question about performance and space

[San Martino]

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 the client.  Normally you would just check out
>>> workspaces of one or more locations where you intend to work and if you
>>> branch or tag, switch an existing workspace to it (to make changes in a
>>> branch or build from the tag, which by convention should not have
>>> subsequent
>>> changes).  Just be sure you have committed anything that belongs in the
>>> current location before the switch. If checkout time is an issue you can
>>> copy an existing local workspace as the starting point for a subsequent
>>> switch.
>>
>>
>> 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 repository. How we will
>> test the tag is a separate issue.
>> For now also suppose the local wc only contains sparse-checkouts of
>> single files, not the whole /trunk.
>> Also suppose that a reorganization of /trunk is not possible.
>>
>> (concrete tests cannot be done at the moment, I am collecting various
>> opinions based on user experience on big projects, before doing
>> simulations)
>
> Our repo is about 43 Gb now and has more activity than that.  It contains
> multiple projects some of which probably have more then 5000 files, although
> not in a flat directory. I don't see any scaling issue unless you meant to
> say 500 Gb.  However, there may be network issues if your clients do not
> have good connectivity and windows clients may be slow if you do check out
> the whole mess due to their local filesystem.  You might want to make sure
> that anything you do that requires frequent full checkouts is on a machine
> with good connectivity to the server even if you have to provide remote
> access for people using it.

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

Re: Question about performance and space

[Erik Huelsmann]

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 average.
>>> Each commit is tagged (yes) from /trunk on the repository. How we will
>>> test the tag is a separate issue.
>>
>> Why would you want to tag each commit? A commit is a tag in itself:
>> there's a unique identifier to refer to the entire commit. This wasn't
>> the case in PVCS, RCS and CVS, but there's really no reason to tag
>> each and every commit; if you want to check out what got committed,
>> just use the revision number!
>
> 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 very frequent. Now with
> Subversion we want to profit by concurrent progrommaing and testing.

You can continue on trunk/ even if you're testing an older revision of
it. Why do you need it to be in /tags before you can test it? What/why
would testing on trunk/ block your coding work on trunk?

My point is: in subversion trunk/ is an endless string of tags,
identified by their (global!) revision number. There's no need to stop
working on trunk while you test older versions. If you look at this
page: 
http://ci.apache.org/waterfall?show=svn-x86-macosx-gnu%20shared&show=svn-x86-macosx-gnu%20shared%20daily%20ra_serf&show=svn-slik-w2k3-x64-local&show=svn-slik-w2k3-x64-ra&show=svn-x64-centos%20gcc&show=svn-x64-ubuntu%20gcc&show=svn-debian-x86_64-32%20shared%20gcc&show=svn-trunk-rat-report

that's what the Subversion team itself is doing: commits keep coming
in; the builders lag, but catch up eventually (mostly at night :-)
We're 100% sure the builders get coherent snapshots, because that's
what the global revision number gives us.


Bye,

Erik.

Re: Question about performance and space

[Ulrich Eckhardt]

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 very frequent. Now with
> Subversion we want to profit by concurrent progrommaing and testing.

So you want to run regression tests on every commit. This is possible without 
additionally tagging every commit. I'd suggest the following approach:
Write a post-commit hook that adds an entry to the test queue. This just adds 
the entry and doesn't run the test because they are time-intensive and you 
don't want to block the finalization of the commit. The entry consists of the 
URL and the revision to be tested. In a separate process (e.g. cronjob) you 
pop an entry from the queue, check out that URL and revision (or update the 
working copy to that revision) and run the test on the code.

Alternatively, you could fork a process in the post-commit hook that checks 
out the code and runs the tests in parallel. Maybe that would be even easier 
than using a separate queue.

Anyway, the point is that you don't need a separate name in the URL because it 
only duplicates the already available URL/revision.


Cheers!

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

mime/confusing checkout error

[d]

Odd issues after converting to subversion.

Binary files that have only one revision seem to be giving us
checkin/checkout problems.  I can use Tortoise SVN to "Open" the files, and
they display fine.  I can "save as" from the web front end, and the files
are fine.

however, when I check the files out, they are broken, corrupted, or give
"inconsistent line ending style" (tortoise).

What is even weirder is that I can check out the broken files, save a good
version over the top of the broke files, commit the non-broken version, and
it still ends up broken when I try to check out again.

I've tried manually setting the mimetype properties, and that hasnt worked.


i'm basically at a loss on how I can make these "right". Any suggestions on
things I can check?

tia,
d

Re: Question about performance and space

[Les Mikesell]

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 on many files might do a 
complete checkout and just update/commit from that workspace from then 
on.  Someone with limited bandwidth or that doesn't want to take up the 
space to keep a working copy around all the time might do a sparse 
checkout of only the files he needs to modify and commit back.


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 explicit tags, 
every commit is atomic and increases the global repository revision 
number.  You can recall the state of all or any part of the repository 
at any revision by including the '-r rev' option in your checkout or 
update command.  In some other version control systems you have to 
assign tags to hold groups of files together, but in subversion you get 
the natural grouping of directories with the global revision number 
holding the state after every change.  Copying to tags just gives you a 
different name for it.  If you are doing something to test after each 
commit, you can just use the revision number and if you tag at all, only 
do it for versions that you have some reason to recall for some other 
purpose later.


And by the way, if you can automate your testing, you might like Hudson 
to run the jobs for you.  You can set it up to poll subversion for 
changes frequently and run jobs (even on different machines) when they 
happen. http://hudson-ci.org/


--
  Les Mikesell
   lesmikes...@gmail.com

Re: mime/confusing checkout error

[Ryan Schmidt]

On Nov 12, 2010, at 09:57, d wrote:

> Binary files that have only one revision seem to be giving us 
> checkin/checkout problems.  I can use Tortoise SVN to "Open" the files, and 
> they display fine.  I can "save as" from the web front end, and the files are 
> fine.
> 
> however, when I check the files out, they are broken, corrupted, or give 
> "inconsistent line ending style" (tortoise).

If they're binary, there shouldn't be anything looking at their line ending 
style. Line ending style is a concept applicable only to text files. I suspect 
you have asked Subversion to corrupt these files by setting the "svn:eol-style" 
property to some value on these files. So you should delete that property from 
these files, then replace them with good copies of the files. Don't set 
svn:eol-style on binary files.

Re: Question about performance and space

[San Martino]

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 explicit tags, every commit is atomic
> and increases the global repository revision number.  You can recall the
> state of all or any part of the repository at any revision by including the
> '-r rev' option in your checkout or update command.  In some other version
> control systems you have to assign tags to hold groups of files together,
> but in subversion you get the natural grouping of directories with the
> global revision number holding the state after every change.  Copying to
> tags just gives you a different name for it.  If you are doing something to
> test after each commit, you can just use the revision number and if you tag
> at all, only do it for versions that you have some reason to recall for some
> other purpose later.
>
> And by the way, if you can automate your testing, you might like Hudson to
> run the jobs for you.  You can set it up to poll subversion for changes
> frequently and run jobs (even on different machines) when they happen.
> http://hudson-ci.org/

Many thanks !

Re: mime/confusing checkout error

[d]

On Fri, Nov 12, 2010 at 12:21 PM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

>
> On Nov 12, 2010, at 09:57, d wrote:
>
> > Binary files that have only one revision seem to be giving us
> checkin/checkout problems.  I can use Tortoise SVN to "Open" the files, and
> they display fine.  I can "save as" from the web front end, and the files
> are fine.
> >
> > however, when I check the files out, they are broken, corrupted, or give
> "inconsistent line ending style" (tortoise).
>
> If they're binary, there shouldn't be anything looking at their line ending
> style. Line ending style is a concept applicable only to text files. I
> suspect you have asked Subversion to corrupt these files by setting the
> "svn:eol-style" property to some value on these files. So you should delete
> that property from these files, then replace them with good copies of the
> files. Don't set svn:eol-style on binary files.
>
>
Thanks so much Ryan.  Removing the svn:eol-style prop and reseeding the
files worked great.

Subversion vs multicore processors

[Dominic Lemire]

Hello,

Does anyone know if a Subversion server can make use of multiple CPU cores
to speed-up long operations? (not just simultaneous requests)

I'm profiling my (dual core) server running subversion 1.4.2 (and trac
wiki), and I realized the CPU usage often tops at 50% during big checkouts
(probably using only 1 core).

I would love to find options that would enable multithread in Subversion
(even if it means I have to recompile apache, subversion and/or the kernel)

Thank you,

Dominic

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/12/10 6:11 PM, Dominic Lemire wrote:

Hello,

Does anyone know if a Subversion server can make use of multiple CPU cores to
speed-up long operations? (not just simultaneous requests)

I'm profiling my (dual core) server running subversion 1.4.2 (and trac wiki),
and I realized the CPU usage often tops at 50% during big checkouts (probably
using only 1 core).

I would love to find options that would enable multithread in Subversion (even
if it means I have to recompile apache, subversion and/or the kernel)



I'm not sure if it will make a difference in that respect, but if you are 
looking to improve things why are you using such an old version?


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Subversion vs multicore processors

[Nico Kadel-Garcia]

On Fri, Nov 12, 2010 at 8:22 PM, Les Mikesell  wrote:
> On 11/12/10 6:11 PM, Dominic Lemire wrote:
>>
>> Hello,
>>
>> Does anyone know if a Subversion server can make use of multiple CPU cores
>> to
>> speed-up long operations? (not just simultaneous requests)
>>
>> I'm profiling my (dual core) server running subversion 1.4.2 (and trac
>> wiki),
>> and I realized the CPU usage often tops at 50% during big checkouts
>> (probably
>> using only 1 core).
>>
>> I would love to find options that would enable multithread in Subversion
>> (even
>> if it means I have to recompile apache, subversion and/or the kernel)
>>
>
> I'm not sure if it will make a difference in that respect, but if you are
> looking to improve things why are you using such an old version?

RHEL 5 still directly only provides Subversion 1.4.2. EPEL will not
replace it in their "Fedora backported" repositories, and you have to
reach out to RPMforge to get a reliable update or pull in the
CollabNet version, which has an entirely different structure, no
source code, and is frankly bloated for most casual use. (Commercial
support can be nice, but most of us don't need that for Subversion.)

RHEL 6, released a few days ago, is up to 1.6.11, but it's awkward to
backport due to various dependencies.

Re: Subversion vs multicore processors

[Les Mikesell]

On 11/12/10 8:09 PM, Nico Kadel-Garcia wrote:

On Fri, Nov 12, 2010 at 8:22 PM, Les Mikesell  wrote:

On 11/12/10 6:11 PM, Dominic Lemire wrote:


Hello,

Does anyone know if a Subversion server can make use of multiple CPU cores
to
speed-up long operations? (not just simultaneous requests)

I'm profiling my (dual core) server running subversion 1.4.2 (and trac
wiki),
and I realized the CPU usage often tops at 50% during big checkouts
(probably
using only 1 core).

I would love to find options that would enable multithread in Subversion
(even
if it means I have to recompile apache, subversion and/or the kernel)



I'm not sure if it will make a difference in that respect, but if you are
looking to improve things why are you using such an old version?


RHEL 5 still directly only provides Subversion 1.4.2. EPEL will not
replace it in their "Fedora backported" repositories, and you have to
reach out to RPMforge to get a reliable update or pull in the
CollabNet version, which has an entirely different structure, no
source code, and is frankly bloated for most casual use. (Commercial
support can be nice, but most of us don't need that for Subversion.)

RHEL 6, released a few days ago, is up to 1.6.11, but it's awkward to
backport due to various dependencies.



The rpmforge version works - but because of other incompatibilities I  generally 
keep the the repo disabled in yum and explicitly:

yum --enablerepo=rpmforge update subversion mod_dav_svn  viewvc (etc.)
when I want to use it for specific packages.

--
   Les Mikesell
lesmikes...@gmail.com

RE: Subversion vs multicore processors

[Edward Ned Harvey]

> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> 
> RHEL 5 still directly only provides Subversion 1.4.2. EPEL will not
replace it in

On RHEL4 / RHEL5, I find it ridiculously easy to build svn from source.
Here is my build script:

#!/bin/bash
VERSION=1.6.12
INSTALLDIR=/usr/local/subversion-$VERSION
SRCDIR=${INSTALLDIR}/src

mkdir -p $SRCDIR
cp subversion-${VERSION}.tar.bz2 $SRCDIR
cp subversion-deps-${VERSION}.tar.bz2 $SRCDIR
cd $SRCDIR

tar xjf subversion-${VERSION}.tar.bz2
tar xjf subversion-deps-${VERSION}.tar.bz2
rm subversion-${VERSION}.tar.bz2
rm subversion-deps-${VERSION}.tar.bz2

mv subversion-${VERSION}/* .
rmdir subversion-${VERSION}
./configure --prefix=$INSTALLDIR --with-ssl && \
make && \
make install && \
echo "" && \
echo "installed ok:  ${INSTALLDIR}/bin/svn"

cd -