> 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-$
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 p
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) ser
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 o
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
(probab
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
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
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 t
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
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
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
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
>>>
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
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
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
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
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
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 h
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
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 instal
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 [ma
21 matches
Mail list logo
