Ryan Schmidt wrote:
> It's clear that Subversion, like CVS, is built around the "work on the
> local machine" mentality, and that this works well for projects with
> far-flung developers where the end result is a compiled executable. But
> as I'll try to explain, this doesn't work so well for projects which are
> PHP/MySQL web sites with a team of developers working in one office
> building. The fact that it's a web site means the working copy needs to
> be on a web server, and the fact that the development team is physically
> located together means a central server is the right model.
>
It works great for websites. We use it every day for many websites that
are developed on different servers, some of which everyone keeps a local
copy on a local server, some of which there's remote working copies on a
central server. The only constraint that SVN places upon your
development is that the working copy is accessible as a regular
filesystem (be it on a local disk or mounted via
ftp/webdav/nfs/samba/whathaveyou).
>> [...] If you want the WC on the server, just run the client tools
>> from the server.
Or make the working copy accessible as a mount on the local developer's
machine.
> I can't speak for JC, but for my company, I am the Apache administrator.
> Most of our programmers don't know how to be Apache administrators, nor
> are they the kind of people who need to be learning that kind of thing.
> It's not in their job descriptions; it's in mine. Our Apache
> configuration is somewhat involved, as is our PHP configuration, and
> let's not forget about the database and all the libraries and
> executables (ImageMagick, GraphViz, gettext, latex, PEAR modules, etc.)
> that are needed. It's not an effective use of anyone's time to replicate
> that setup when we can have it on a central server.
I can say from experience that it's crucial to be able to set up a
server environment as quickly and correctly as possible. One way (and
only one of many ways) to "practice" that is to set up the server
environment on developers' machines. When it comes time to replace that
production server in a real hurry, you'll know just how to do it.
The other option, and what I think the OP really wants, is some sort of
"working copy server" that is analagous to a "repository server". That
way, a SVN client could use a remote working copy through the "working
copy server" or a local working copy via the filesystem. Implementing
this, however, would be reinventing the wheel: "working copy" servers
exist already, called samba, NFS, Apache/WebDAV, etc, etc, etc. Those
servers also have the benefit of making your "remote working copy" show
up as a local filesystem, allowing you to use all sorts of non-"remote
working copy"-aware tools on it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 21:50:13 2005