On Fri, Feb 10, 2012 at 11:29 PM, Bruce Lysik wrote:
> We have a single server installation which is currently not fast enough.
>
> The LB pair + 3 svn front-ends + SAN storage is not strictly for
> performance, but also for reliability. Scaling vertically would probably
> solve performance probl
We have a single server installation which is currently not fast enough.
The LB pair + 3 svn front-ends + SAN storage is not strictly for performance,
but also for reliability. Scaling vertically would probably solve performance
problems in the short term, but still wouldn't address single p
On Fri, Feb 10, 2012 at 04:47:31PM -0600, Ryan Schmidt wrote:
> So thinking all this through, I agree svnsync does not make sense if
> you are hosting a repository on a SAN and trying to connect multiple
> svn servers to it. But it sounds like it would work fine, if you
> simply don't use svnsync.
On Feb 10, 2012, at 16:34, Stefan Sperling wrote:
> On Fri, Feb 10, 2012 at 04:20:02PM -0600, Ryan Schmidt wrote:
>>> While replicating commits, svnsync performs the exact same kinds of
>>> write operations against the slave servers that happen on the master
>>> repository when a client makes a c
On Fri, Feb 10, 2012 at 04:20:02PM -0600, Ryan Schmidt wrote:
> > While replicating commits, svnsync performs the exact same kinds of
> > write operations against the slave servers that happen on the master
> > repository when a client makes a commit.
>
> So when using svnsync one should always us
On Feb 10, 2012, at 16:16, Stefan Sperling wrote:
> On Fri, Feb 10, 2012 at 04:09:45PM -0600, Ryan Schmidt wrote:
>> you could consider having any
>> number of read-only slave servers, which would each proxy their write
>> requests back to the single master server that Subversion supports.
>> This
On Fri, Feb 10, 2012 at 04:09:45PM -0600, Ryan Schmidt wrote:
> Have you verified that a single server will not be fast enough?
Good point. It might very well be fast enough.
> If so, you could consider having any
> number of read-only slave servers, which would each proxy their write
> requests
On Feb 10, 2012, at 15:00, Nico Kadel-Garcia wrote:
> On Fri, Feb 10, 2012 at 1:21 PM, Bruce Lysik wrote:
>>
>> I'm considering deploying 3 front-ends, all mounting the same SAN volume for
>> repo. (The SAN handle flock() and fnctl() correctly.) These 3 FEs would be
>> load balanced by a Citri
On Fri, Feb 10, 2012 at 04:00:02PM -0500, Nico Kadel-Garcia wrote:
> On Fri, Feb 10, 2012 at 1:21 PM, Bruce Lysik wrote:
> > Hi,
> >
> > I'm considering deploying 3 front-ends, all mounting the same SAN volume for
> > repo. (The SAN handle flock() and fnctl() correctly.) These 3 FEs would be
> >
To all who helped me.
Thanks a lot for your kind helps.
Finally, I found that it was my environment issue. There was "usr/bin/ssh"
in my "Users/account/.ssh/config" file. It couldn't seen from Mac's Finder
as its name starts with ".".
I used Terminal.app to correct it to "/usr/bin/ssh" and succe
On Fri, Feb 10, 2012 at 1:21 PM, Bruce Lysik wrote:
> Hi,
>
> I'm considering deploying 3 front-ends, all mounting the same SAN volume for
> repo. (The SAN handle flock() and fnctl() correctly.) These 3 FEs would be
> load balanced by a Citrix Netscaler. (At least for http(s).)
>
> Would there
Hi,
I'm considering deploying 3 front-ends, all mounting the same SAN volume for
repo. (The SAN handle flock() and fnctl() correctly.) These 3 FEs would be
load balanced by a Citrix Netscaler. (At least for http(s).)
Would there be any problems with this configuration?
--
Bruce Z. Lysik
> TortoiseSVN newer than 1.6.16 causes errors in our software build process
Good to know.
Seriously, did you have a specific question?
BOb
Am 10.02.2012 00:34, schrieb Ajay Mahagaokar:
I am using TortoiseSVN for the first time and got immediately into
trouble. My setup:
1. Win7 64-bit
2. VirtualBox with Win7 as host
3. VM is VirtualBox Guest is Ubuntu 10.04 LTS (up to date).
4. SVN Server is networked and a
14 matches
Mail list logo
