You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Ferguson <fe...@gmail.com> on 2007/05/07 12:59:45 UTC
Setting up a Subversion server farm
Could you guys take a look at my plan for setting up a Subversion server
farm and let me know if you see any gotchas?
1. There will be six machines running svnserve, all pointing to the same
root (-r option). This root will be an NFS mount of a directory that
contains the many repositories for the projects that this farm must serve.
2. Each machine will have a unique name in DNS like svn1.mydomain.com,
svn2.mydomain.com, etc. but will always be accessed by clients through
svn.mydomain.com. To provide some load balancing, svn.mydomain.com will be
an alias that will map to specific svnX.mydomain.com servers in a
round-robin fashion.
3. No authentication will be done (this is all behind the company firewall
and all users are trusted)
4. All repositories are using FSFS.
See any issues? I am most interested in this: Is it okay to have multiple
machines running svnserve, possibly accessing the same repository at the
same time? From all I read it is, but I just wanted to be sure.
thanks in advance,
David
Re: Setting up a Subversion server farm
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting Ryan Schmidt <su...@ryandesign.com>:
> On May 7, 2007, at 07:59, David Ferguson wrote:
>
>> 1. There will be six machines running svnserve, all pointing to the
>> same root (-r option). This root will be an NFS mount of a
>> directory that contains the many repositories for the projects that
>> this farm must serve.
>
> This plan sounds similar to what I've been thinking of, though having
> the svnserves access the repository via NFS is probably a bad idea. In
> my setup, I will be using a SAN, which should not have any of the
> problems typically associated with NFS.
Will there be any concurrency issues with 6 svnserve instances running
against the same root - be it on NFS or SAN?
--
Jing Xue
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Jared Hardy <ja...@gmail.com>.
On 5/10/07, Ryan Schmidt <su...@ryandesign.com> wrote:
> I should further clarify that my understanding of SANs is limited to
> Apple's documentation of their Xsan product, which I believe is a
> cluster filesystem, so apparently I don't know know where a SAN stops
> and a cluster filesystem begins. So wherever I have said "SAN" in
> previous postings, please substitute "SAN with cluster filesystem" or
> "Apple Xsan."
An easy way to say this is "SAN volume = networked hard drive volume;
Cluster File System ON SAN volume = Network Accessible File System."
You wouldn't really ever want to give two systems simultaneous
write access to the same volume, at the block level that any SAN
operates on. Cluster File Systems, like RedHat GFS and the Oracle CFS
(and whatever Xsan uses as an FS), are just like regular file systems,
except they also handle the semaphores and resource locking necessary
for simultaneous multi-node access.
In my jaded opinion, the very names of NFS and CIFS are based on
misnomers -- I really just view them as complex structured file
transfer protocols, with lower overhead transfer initiation routines
than more "traditional" file transfer protocols, like FTP or HTTP. I
think of WebDAVfs as functionally equivalent to NFS and CIFS in most
areas, and that's really running on top of the HTTP stack. None of
them replace the need for a true CFS.
It is possible to use Cluster or Cluster-Aware File Systems on any
"shared" hard drive or RAID volumes. If it isn't on a SAN of some
sort, it's usually a single RAID box with two SCSI connections, to two
different servers. This naturally limits you to 2-node clusters, which
usually just end up being High-Availability fail-over type clusters,
rather than true Load Balancing clusters. HA Clusters don't need
simultaneous R/W access, except for a special small "Quorum" volume
that contains failure and priority status data (which is like a
minimal CFS on its own), so Cluster-Aware FS or OS layers are
sufficient for HA systems. True shared CFS is necessary for Load
Balancing Clusters that complete Write operations of any sort, and
SANs are necessary to mount a single CFS partition on more than 2
nodes simultaneously.
Most Load Balanced clusters also utilize a router or reverse-proxy
of some sort, which controls how clients access each node, and defines
a single name and/or IP for all client access. Better routers often
handle problems like cache coherence, and secure client-server
multiple transaction static routing.These firewall/reverse-proxy
cluster routers are also often hosted on HA type Clusters themselves,
to prevent any single point of failure.
I can't wait for SVN 1.5 to get stable -- the HTTP/S reverse-proxy
capability will allow for LB Cluster router nodes to simultaneously
act as Read operation load balancing nodes, which is amazing. That
feature opens up a lot of opportunities for geographically distributed
load balanced SVN and WebDAV cluster configurations, without any cache
issues. My remote employees and contractors will rejoice, and I may
get to work from home more often.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 10, 2007, at 01:36, Matthew Hannigan wrote:
> On Thu, May 10, 2007 at 01:27:35AM -0500, Ryan Schmidt wrote:
>>
>> My understanding of SANs is that they are seen by the OS the same way
>> that a local hard disk is seen,
>
> true but ...
>
>> and also that it is perfectly safe
>> for multiple machines to attempt to read from and write to files on
>> the SAN concurrently, because the SAN will manage these requests in a
>> way that prevents problems.
>
> This doesn't apply. SANs are shared but tyipcally not the
> individual disks
> /volumes from a SAN box. Clusters do that, but still not
> simultaneously.
I should further clarify that my understanding of SANs is limited to
Apple's documentation of their Xsan product, which I believe is a
cluster filesystem, so apparently I don't know know where a SAN stops
and a cluster filesystem begins. So wherever I have said "SAN" in
previous postings, please substitute "SAN with cluster filesystem" or
"Apple Xsan."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Matthew Hannigan <ml...@zip.com.au>.
On Thu, May 10, 2007 at 01:27:35AM -0500, Ryan Schmidt wrote:
>
> My understanding of SANs is that they are seen by the OS the same way
> that a local hard disk is seen,
true but ...
> and also that it is perfectly safe
> for multiple machines to attempt to read from and write to files on
> the SAN concurrently, because the SAN will manage these requests in a
> way that prevents problems.
This doesn't apply. SANs are shared but tyipcally not the individual disks
/volumes from a SAN box. Clusters do that, but still not simultaneously.
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Ryan Schmidt <su...@ryandesign.com>.
Please pardon my liberal snippage below:
On May 9, 2007, at 16:48, Matt Sickler wrote:
> > On 5/7/07, Ryan Schmidt wrote:
> >
> >> On May 7, 2007, at 07:59, David Ferguson wrote:
> >>
> >> > Could you guys take a look at my plan for setting up a Subversion
> >> > server farm and let me know if you see any gotchas?
> >> This plan sounds similar to what I've been thinking of, though
> having
> >> the svnserves access the repository via NFS is probably a bad idea.
> >> In my setup, I will be using a SAN, which should not have any of
> the
> >> problems typically associated with NFS.
> the idea is that no matter what server you use (svnserve for svn://
> and apache for http:// and https://), the server access a local
> hard disk for the repo - if it has to use the network to get at it
> and/or you have multiple servers trying to use the same repo,
> problems WILL arise eventually
My understanding of SANs is that they are seen by the OS the same way
that a local hard disk is seen, and also that it is perfectly safe
for multiple machines to attempt to read from and write to files on
the SAN concurrently, because the SAN will manage these requests in a
way that prevents problems. And though the server does have to use a
network to get the data, it's (ideally) a network dedicated to
handling SAN traffic, so it's no worse than accessing the data from,
say, a SCSI disk on a SCSI "network" (bus). Therefore, I understood
that it is perfectly safe (and wonderful) to host a Subversion
repository on a SAN accessed by any number of servers. I believe I
recall reading messages on this list some time ago from someone who
was doing this successfully. However, I should reiterate that I have
not attempted this setup myself yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Daniel Berlin <db...@dberlin.org>.
On 5/9/07, David Ferguson <fe...@gmail.com> wrote:
> Please forgive me, but svnsync is completely useless in this situation. My
> users are all over the world at many different sites. They are all
> permitted to make changes and there would never be a case where a user would
> want a read-only copy. Therefore, svnsync can't help at all.
>
> My IT department is heavily invested in NFS and will never be swayed to use
> anything else. All interactive machines (such as my Subversion servers)
> mount all file systems via NFS from filers. I can't change that,
> unfortunately.
>
> Can anyone else comment on Matt's statement that Subversion repositories may
> not exist on NFS shares without problems, regardless of the repository
> access method used (svn://, svn+ssh://, http://, file://)?
As a general statement, it's wrong.
> If this is true,
> I'm completely shocked--our company will be forced to go back to CVS or
> worse, Clearcase.
Subversion repositories can exist on NFS shares without problems,
assuming your NFS implementation has working file locking
However, until 1.5, there are some situations where multiple servers
accessing the same NFS repository at the same time will cause some
commits to fail due to the stale file handle issue of NFS.
When i say multiple servers, i really mean multiple servers. There is
no problem with a single server accessing an NFS share.
This will not cause repository corruption, but is kind of annoying.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Blair Zajac <bl...@orcaware.com>.
David Ferguson wrote:
> Please forgive me, but svnsync is completely useless in this situation.
> My users are all over the world at many different sites. They are all
> permitted to make changes and there would never be a case where a user
> would want a read-only copy. Therefore, svnsync can't help at all.
>
> My IT department is heavily invested in NFS and will never be swayed to
> use anything else. All interactive machines (such as my Subversion
> servers) mount all file systems via NFS from filers. I can't change
> that, unfortunately.
>
> Can anyone else comment on Matt's statement that Subversion repositories
> may not exist on NFS shares without problems, regardless of the
> repository access method used (svn://, svn+ssh://, http://, file://)?
> If this is true, I'm completely shocked--our company will be forced to
> go back to CVS or worse, Clearcase.
Collab.net uses BDB on NetApp I believe. I have had bad luck in the past with
BDB, but the code has been fixed since and if you use BDB 4.4 or greater.
I haven't personally used BDB for a couple of years, but you can give it a shot.
Presumably, using Collab.net's svn build would be a safe way to go, if they use
the same build for their hosting solution.
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Tehmurasp Ghyara <te...@oracle.com>.
David Ferguson wrote:
[snip]
> Can anyone else comment on Matt's statement that Subversion repositories
> may not exist on NFS shares without problems, regardless of the
> repository access method used (svn://, svn+ssh://, http://, file://)?
> If this is true, I'm completely shocked--our company will be forced to
> go back to CVS or worse, Clearcase.
I haven't tried this but maybe this link could help:
http://woss.name/2005/08/25/subversion-and-nfs-file-locking/#comment-336
Ciao and regards
TG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by David Ferguson <fe...@gmail.com>.
Please forgive me, but svnsync is completely useless in this situation. My
users are all over the world at many different sites. They are all
permitted to make changes and there would never be a case where a user would
want a read-only copy. Therefore, svnsync can't help at all.
My IT department is heavily invested in NFS and will never be swayed to use
anything else. All interactive machines (such as my Subversion servers)
mount all file systems via NFS from filers. I can't change that,
unfortunately.
Can anyone else comment on Matt's statement that Subversion repositories may
not exist on NFS shares without problems, regardless of the repository
access method used (svn://, svn+ssh://, http://, file://)? If this is true,
I'm completely shocked--our company will be forced to go back to CVS or
worse, Clearcase.
thanks,
David
On 5/9/07, Matt Sickler <cr...@gmail.com> wrote:
>
> the idea is that no matter what server you use (svnserve for svn:// and
> apache for http:// and https://), the server access a local hard disk for
> the repo - if it has to use the network to get at it and/or you have
> multiple servers trying to use the same repo, problems WILL arise eventually
>
> file:/// should never be used except for private, single-user, local repos
>
> if you need multiple servers, use the svnsync method described in the
> book:
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnsync
>
> On 5/9/07, Ryan Schmidt < subversion-2007b@ryandesign.com> wrote:
>
> > Please keep replies on the list so everyone can benefit from the
> > discussion. More below:
> >
> > On May 9, 2007, at 08:45, David Ferguson wrote:
> >
> > > On 5/7/07, Ryan Schmidt wrote:
> > >
> > >> On May 7, 2007, at 07:59, David Ferguson wrote:
> > >>
> > >> > Could you guys take a look at my plan for setting up a Subversion
> > >> > server farm and let me know if you see any gotchas?
> > >> >
> > >> > 1. There will be six machines running svnserve, all pointing to the
> > >> > same root (-r option). This root will be an NFS mount of a
> > >> > directory that contains the many repositories for the projects that
> > >> > this farm must serve.
> > >> >
> > >> > 2. Each machine will have a unique name in DNS like
> > >> > svn1.mydomain.com, svn2.mydomain.com , etc. but will always be
> > >> > accessed by clients through svn.mydomain.com . To provide some
> > load
> > >> > balancing, svn.mydomain.com will be an alias that will map to
> > >> > specific svnX.mydomain.com servers in a round-robin fashion.
> > >> >
> > >> > 3. No authentication will be done (this is all behind the company
> > >> > firewall and all users are trusted)
> > >> >
> > >> > 4. All repositories are using FSFS.
> > >> >
> > >> > See any issues? I am most interested in this: Is it okay to have
> > >> > multiple machines running svnserve, possibly accessing the same
> > >> > repository at the same time? From all I read it is, but I just
> > >> > wanted to be sure.
> > >>
> > >> This plan sounds similar to what I've been thinking of, though having
> > >> the svnserves access the repository via NFS is probably a bad idea.
> > >> In my setup, I will be using a SAN, which should not have any of the
> > >> problems typically associated with NFS.
> > >
> > > Are you kidding? I thought if I avoided BerkleyDB then I could put
> > > the repository on an NFS share without trouble, regardless of what
> > > access method I used (file, svnserve-daemon, svnserve-tunnel, or
> > > http). I just searched the Subversion manual for "NFS" and found
> > > nothing about svnserve being incompatible with NFS.
> > >
> > > Does svnserve through a tunnel have the same NFS problems as
> > > svnserve as a daemon? We're using svnserve through tunnel right
> > > now and we don't have any problems.
> > >
> > > So what are the "NFS safe" methods? file:// and http://??
> >
> > It wasn't my intention to kid. To be honest I've never used NFS for
> > anything. But I have seen posts on this mailing list from people who
> > had problems with repositories on NFS and the problem was resolved by
> > not using NFS anymore. I do not know if there is such a thing as an
> > "NFS-safe" repository access method. I also can't tell you about
> > tunnels as I've never used those before either. Maybe someone else on
> > the list will have more useful answers for you.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
Re: Setting up a Subversion server farm
Posted by Matt Sickler <cr...@gmail.com>.
the idea is that no matter what server you use (svnserve for svn:// and
apache for http:// and https://), the server access a local hard disk for
the repo - if it has to use the network to get at it and/or you have
multiple servers trying to use the same repo, problems WILL arise eventually
file:/// should never be used except for private, single-user, local repos
if you need multiple servers, use the svnsync method described in the book:
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.tk.svnsync
On 5/9/07, Ryan Schmidt <su...@ryandesign.com> wrote:
>
> Please keep replies on the list so everyone can benefit from the
> discussion. More below:
>
> On May 9, 2007, at 08:45, David Ferguson wrote:
>
> > On 5/7/07, Ryan Schmidt wrote:
> >
> >> On May 7, 2007, at 07:59, David Ferguson wrote:
> >>
> >> > Could you guys take a look at my plan for setting up a Subversion
> >> > server farm and let me know if you see any gotchas?
> >> >
> >> > 1. There will be six machines running svnserve, all pointing to the
> >> > same root (-r option). This root will be an NFS mount of a
> >> > directory that contains the many repositories for the projects that
> >> > this farm must serve.
> >> >
> >> > 2. Each machine will have a unique name in DNS like
> >> > svn1.mydomain.com, svn2.mydomain.com , etc. but will always be
> >> > accessed by clients through svn.mydomain.com. To provide some load
> >> > balancing, svn.mydomain.com will be an alias that will map to
> >> > specific svnX.mydomain.com servers in a round-robin fashion.
> >> >
> >> > 3. No authentication will be done (this is all behind the company
> >> > firewall and all users are trusted)
> >> >
> >> > 4. All repositories are using FSFS.
> >> >
> >> > See any issues? I am most interested in this: Is it okay to have
> >> > multiple machines running svnserve, possibly accessing the same
> >> > repository at the same time? From all I read it is, but I just
> >> > wanted to be sure.
> >>
> >> This plan sounds similar to what I've been thinking of, though having
> >> the svnserves access the repository via NFS is probably a bad idea.
> >> In my setup, I will be using a SAN, which should not have any of the
> >> problems typically associated with NFS.
> >
> > Are you kidding? I thought if I avoided BerkleyDB then I could put
> > the repository on an NFS share without trouble, regardless of what
> > access method I used (file, svnserve-daemon, svnserve-tunnel, or
> > http). I just searched the Subversion manual for "NFS" and found
> > nothing about svnserve being incompatible with NFS.
> >
> > Does svnserve through a tunnel have the same NFS problems as
> > svnserve as a daemon? We're using svnserve through tunnel right
> > now and we don't have any problems.
> >
> > So what are the "NFS safe" methods? file:// and http://??
>
> It wasn't my intention to kid. To be honest I've never used NFS for
> anything. But I have seen posts on this mailing list from people who
> had problems with repositories on NFS and the problem was resolved by
> not using NFS anymore. I do not know if there is such a thing as an
> "NFS-safe" repository access method. I also can't tell you about
> tunnels as I've never used those before either. Maybe someone else on
> the list will have more useful answers for you.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Setting up a Subversion server farm
Posted by Ryan Schmidt <su...@ryandesign.com>.
Please keep replies on the list so everyone can benefit from the
discussion. More below:
On May 9, 2007, at 08:45, David Ferguson wrote:
> On 5/7/07, Ryan Schmidt wrote:
>
>> On May 7, 2007, at 07:59, David Ferguson wrote:
>>
>> > Could you guys take a look at my plan for setting up a Subversion
>> > server farm and let me know if you see any gotchas?
>> >
>> > 1. There will be six machines running svnserve, all pointing to the
>> > same root (-r option). This root will be an NFS mount of a
>> > directory that contains the many repositories for the projects that
>> > this farm must serve.
>> >
>> > 2. Each machine will have a unique name in DNS like
>> > svn1.mydomain.com, svn2.mydomain.com , etc. but will always be
>> > accessed by clients through svn.mydomain.com. To provide some load
>> > balancing, svn.mydomain.com will be an alias that will map to
>> > specific svnX.mydomain.com servers in a round-robin fashion.
>> >
>> > 3. No authentication will be done (this is all behind the company
>> > firewall and all users are trusted)
>> >
>> > 4. All repositories are using FSFS.
>> >
>> > See any issues? I am most interested in this: Is it okay to have
>> > multiple machines running svnserve, possibly accessing the same
>> > repository at the same time? From all I read it is, but I just
>> > wanted to be sure.
>>
>> This plan sounds similar to what I've been thinking of, though having
>> the svnserves access the repository via NFS is probably a bad idea.
>> In my setup, I will be using a SAN, which should not have any of the
>> problems typically associated with NFS.
>
> Are you kidding? I thought if I avoided BerkleyDB then I could put
> the repository on an NFS share without trouble, regardless of what
> access method I used (file, svnserve-daemon, svnserve-tunnel, or
> http). I just searched the Subversion manual for "NFS" and found
> nothing about svnserve being incompatible with NFS.
>
> Does svnserve through a tunnel have the same NFS problems as
> svnserve as a daemon? We're using svnserve through tunnel right
> now and we don't have any problems.
>
> So what are the "NFS safe" methods? file:// and http://??
It wasn't my intention to kid. To be honest I've never used NFS for
anything. But I have seen posts on this mailing list from people who
had problems with repositories on NFS and the problem was resolved by
not using NFS anymore. I do not know if there is such a thing as an
"NFS-safe" repository access method. I also can't tell you about
tunnels as I've never used those before either. Maybe someone else on
the list will have more useful answers for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 7, 2007, at 07:59, David Ferguson wrote:
> Could you guys take a look at my plan for setting up a Subversion
> server farm and let me know if you see any gotchas?
>
> 1. There will be six machines running svnserve, all pointing to the
> same root (-r option). This root will be an NFS mount of a
> directory that contains the many repositories for the projects that
> this farm must serve.
>
> 2. Each machine will have a unique name in DNS like
> svn1.mydomain.com, svn2.mydomain.com, etc. but will always be
> accessed by clients through svn.mydomain.com. To provide some load
> balancing, svn.mydomain.com will be an alias that will map to
> specific svnX.mydomain.com servers in a round-robin fashion.
>
> 3. No authentication will be done (this is all behind the company
> firewall and all users are trusted)
>
> 4. All repositories are using FSFS.
>
> See any issues? I am most interested in this: Is it okay to have
> multiple machines running svnserve, possibly accessing the same
> repository at the same time? From all I read it is, but I just
> wanted to be sure.
This plan sounds similar to what I've been thinking of, though having
the svnserves access the repository via NFS is probably a bad idea.
In my setup, I will be using a SAN, which should not have any of the
problems typically associated with NFS.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Setting up a Subversion server farm
Posted by Matt Sickler <cr...@gmail.com>.
svnserve pointing at a NFS share = BAD there will be people who say that
you can mount a repo on NFS shares, but its a very bad idea because it blows
up in unexpected and subtle ways
a better way is to have a master server and then use slave servers and
svnsync. the slaves will only be able to do checkouts, but I have a feeling
that doesnt matter in your case
if you want to be able to track who did what, you need some kind of
authentication, even if they have empty passwords; otherwise you will get
anonymous commits on everything
On 5/7/07, David Ferguson <fe...@gmail.com> wrote:
>
> Could you guys take a look at my plan for setting up a Subversion server
> farm and let me know if you see any gotchas?
>
> 1. There will be six machines running svnserve, all pointing to the same
> root (-r option). This root will be an NFS mount of a directory that
> contains the many repositories for the projects that this farm must serve.
>
> 2. Each machine will have a unique name in DNS like svn1.mydomain.com,
> svn2.mydomain.com, etc. but will always be accessed by clients through
> svn.mydomain.com. To provide some load balancing, svn.mydomain.com will
> be an alias that will map to specific svnX.mydomain.com servers in a
> round-robin fashion.
>
> 3. No authentication will be done (this is all behind the company firewall
> and all users are trusted)
>
> 4. All repositories are using FSFS.
>
> See any issues? I am most interested in this: Is it okay to have
> multiple machines running svnserve, possibly accessing the same repository
> at the same time? From all I read it is, but I just wanted to be sure.
>
>
> thanks in advance,
> David
>
>
Pl/SQL development with subversion.
Posted by Salvador Santander Gutierrez <sa...@juntadeandalucia.es>.
We installed subversion ten moths ago, and it works very well. With eclipse
we haven´t any problem because there's a plugin to work with subversion but
we've many development projects in pl/sql (oracle) and we need to have all
the objects versioned in a control version system.
Do you know any PL/SQL development IDE with support for subversion? any
plugin for TOAD, for example?
I've just seen Toby PL/SQL for eclipse, but it haven´t such features than
other comercial IDE's.
Thanks in advance.