On Dec 24, 2007 8:19 AM, alon2 <alon@evolven.com> wrote:
>
>
>
> Erik Huelsmann-2 wrote:
> >
> > On Dec 24, 2007 12:58 PM, alon2 <alon@evolven.com> wrote:
> >>
> >> hi,
> >> I have apache set up and running on one machine with multiple
> >> repositories
> >> on it,using the SVNParentPath in the httpd.conf.
> >> every thing is alright with that.
> >> we want to move our repository(e.g repository files)to another machine
> >> which
> >> is a file server,but the thing is that we want to keep the
> >> server(apache)on
> >> the first machine.
> >> I understood that this is possible...
> >
> > Right. In order to do so, you need a networked file system (such as
> > NFS) which supports file-level locking.
> >
> > Pretty much, that's all you need to do - besides making the filesystem
> > available on the repository server. Maybe others have more advice?
> >
> >> how can I actually do the transfer?what do I need to config?
> >> I'm using apache 2.0.58,and svn, version 1.4.2 (r22196)
> >
> > bye,
> >
> > Erik.
> >
> >
> Erik-I already have that-meaning I can gain access to the file server using
> the \\file-server\ path in the explorer.
> I need more direction according to the httpd.conf configuration...
> I tried to give the SVNPath the \\xxx\ path but it doesn't work.
Because the ID that Apache runs under must have the ability to access that path.
> I also tried
> to map the path on the file server as a vurtual drive and give that to the
> conf file but that didn't work either...
Because drives are mapped at login for the user logging in. For a
service, you really need paths to be drive letters that appear local
to the server when no users are logged in.
You really ought to have the repository on a drive that appears local
to the server (a phsical drive connected to the server, an iSCSI LUN,
a SAN drive, etc.). I really don't understand the need to have it on
an altogether separate server. You're doubling your network latency
and traffic (client to SVN server. SVN server to the server hosting
the repository files themselves) and adding to the configuration and
security headaches.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 24 15:43:24 2007