Re: AW: SVN on docker/kubernetes/openshift - shared storage?

2018-11-27 Thread Branko Čibej
On 27.11.2018 11:25, Tietz, Jonathan wrote:
> Hi,
>
> we have times where the load of our server is getting quite high, so we want 
> to spread the load to different svn-instances.

The first step is to find out what exactly is causing the load; whether
it's commits or updates or something else.


>  As we have TBs of data, we do not want to share these data over different 
> storages. 
>
> But if you say, that (one) shared storage with different svn-instances 
> (mod_subversion) will never work, than ok, I didn't find an answer. Can you 
> confirm?


Subversion itself supports master/slave replication, where all commits
go to a single server but read operations can be served by many. Maybe
that's sufficient for your case, but it's hard to say without any
performance data. Sometimes just tuning the server configuration may be
enough.

> If yes, then we have to thing about a different architecture, eg. many 
> svn-instances each with its own storage

Sure, you can split repositories amongst different servers. Or you can
use a commercial solution that provides master/master replication.

-- Brane


> -Ursprüngliche Nachricht-
> Von: Branko Čibej  
> Gesendet: Freitag, 23. November 2018 12:06
> An: users@subversion.apache.org
> Betreff: Re: SVN on docker/kubernetes/openshift - shared storage?
>
> On 23.11.2018 11:27, Tietz, Jonathan wrote:
>> Hi,
>>
>> we are thinking about to run subversion on a docker/openshift environment.
>>
>> That means we have multiple subversion instances, reading/writing on 
>> subversion repositories saved on one shared storage (currently nfs 
>> filesystem)
>>
>> According to internet, e.g. 
>> https://support.wandisco.com/index.php?/Knowledgebase/Article/View/182
>> /0/why-you-should-not-use-network-file-system-with-git-or-svn
>> You should not use nfs.
>>
>> Has someone else running a similar setup with a shared storage? If yes, what 
>> filesystem are you using?
> What are you trying to achieve with this configuration? Perhaps there's a 
> better way to solve your use-case than using a basically unsupported and 
> possibly broken configuration.
>
> -- Brane



RE: SVN crashing

2018-11-27 Thread Ramesh Belli
Thanks Pavel!

-Original Message-
From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com] 
Sent: Tuesday, November 27, 2018 4:04 AM
To: Ramesh Belli
Cc: users@subversion.apache.org
Subject: Re: SVN crashing

On Tue, Nov 27, 2018 at 10:51 AM Ramesh Belli  wrote:
>
> Hi Sir,
>
> SVN is crashing when I try to download from the trunk.
>
> Can you please point me to the right solution.

The right solution is to upgrade your SVN client and see whether this
resolves the problem.

You use an outdated and unsupported SVN 1.8.9 version:
[[[
1.8.9-SlikSvn-1.8.9-X64 (SlikSvn/1.8.9) X64, compiled May  8 2014, 20:00:31
]]]

--
With best regards,
Pavel Lyalyakin
VisualSVN Team


RE: SVN crashing

2018-11-27 Thread Ramesh Belli
Thanks Johan

-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com] 
Sent: Tuesday, November 27, 2018 4:12 AM
To: Ramesh Belli
Cc: Subversion
Subject: Re: SVN crashing

On Tue, Nov 27, 2018 at 8:51 AM Ramesh Belli  wrote:
>
> Hi Sir,
>
> SVN is crashing when I try to download from the trunk.
>
> Can you please point me to the right solution.

Hi Ramesh,

I see that you're using version 1.8.9 of SVN, which is quite old, and
not supported anymore. So the first thing to try is to upgrade to the
most recent version (preferably 1.11.0 or 1.10.3) and try again.

You can find some links to binary packages for Windows here:
http://subversion.apache.org/packages.html#windows

-- 
Johan


AW: SVN on docker/kubernetes/openshift - shared storage?

2018-11-27 Thread Tietz, Jonathan
Hi,

we have times where the load of our server is getting quite high, so we want to 
spread the load to different svn-instances. As we have TBs of data, we do not 
want to share these data over different storages. 

But if you say, that (one) shared storage with different svn-instances 
(mod_subversion) will never work, than ok, I didn't find an answer. Can you 
confirm?

If yes, then we have to thing about a different architecture, eg. many 
svn-instances each with its own storage

regards

Jonathan

-Ursprüngliche Nachricht-
Von: Branko Čibej  
Gesendet: Freitag, 23. November 2018 12:06
An: users@subversion.apache.org
Betreff: Re: SVN on docker/kubernetes/openshift - shared storage?

On 23.11.2018 11:27, Tietz, Jonathan wrote:
> Hi,
>
> we are thinking about to run subversion on a docker/openshift environment.
>
> That means we have multiple subversion instances, reading/writing on 
> subversion repositories saved on one shared storage (currently nfs 
> filesystem)
>
> According to internet, e.g. 
> https://support.wandisco.com/index.php?/Knowledgebase/Article/View/182
> /0/why-you-should-not-use-network-file-system-with-git-or-svn
> You should not use nfs.
>
> Has someone else running a similar setup with a shared storage? If yes, what 
> filesystem are you using?

What are you trying to achieve with this configuration? Perhaps there's a 
better way to solve your use-case than using a basically unsupported and 
possibly broken configuration.

-- Brane


Re: SVN crashing

2018-11-27 Thread Johan Corveleyn
On Tue, Nov 27, 2018 at 8:51 AM Ramesh Belli  wrote:
>
> Hi Sir,
>
> SVN is crashing when I try to download from the trunk.
>
> Can you please point me to the right solution.

Hi Ramesh,

I see that you're using version 1.8.9 of SVN, which is quite old, and
not supported anymore. So the first thing to try is to upgrade to the
most recent version (preferably 1.11.0 or 1.10.3) and try again.

You can find some links to binary packages for Windows here:
http://subversion.apache.org/packages.html#windows

-- 
Johan


Re: SVN crashing

2018-11-27 Thread Pavel Lyalyakin
On Tue, Nov 27, 2018 at 10:51 AM Ramesh Belli  wrote:
>
> Hi Sir,
>
> SVN is crashing when I try to download from the trunk.
>
> Can you please point me to the right solution.

The right solution is to upgrade your SVN client and see whether this
resolves the problem.

You use an outdated and unsupported SVN 1.8.9 version:
[[[
1.8.9-SlikSvn-1.8.9-X64 (SlikSvn/1.8.9) X64, compiled May  8 2014, 20:00:31
]]]

--
With best regards,
Pavel Lyalyakin
VisualSVN Team