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.
I think this post finally describes the situation that JC finds himself
faced with (and me too):
On 24.01.2005, at 07:16, Ed MacDonald wrote:
> [...] If you want the WC on the server, just run the client tools
> from the server. It's actually pretty easy to do exactly what you
> describe in your "Envisioned workflow".
>
> Configure web and ftp (I'm assuming you are using ftp to sync the site
> in DreamWeaver) servers to serve home accounts (~username).
> Each developer gets an account on the server.
> Developer logs in to server via ssh, telnet, etc. and use svn CLI on
> the server.
> Developer uses svn to check out to their home directory.
> Use Dream Weaver to connect to working copy in developer's home
> directory, make changes, upload, etc.
> Use svn to commit changes.
>
> If you want to use a GUI, connect to your server with VNC, Exceed,
> TerminalServer, etc. and use an existing SVN GUI for your server
> platform.
And it should be obvious why both of these solutions are non-optimal.
Learning the command-line tools is not something JC or I want our
coworkers to need to do, hence the subject line of this thread. (We
don't make our developers ssh to the development server and use vi
either; we install GUI text editors on the client machines, along with
GUI mail clients and so on.) And having a multitude of developers
fighting over a shared remote computer's GUI over VNC, with the
associated performance implications and visual glitches common to VNC,
is also a bad idea. Anyway the server is Linux, and our developers use
Macs and Windows PCs, so even if we did run an X server, the developers
wouldn't want to use a Linux GUI. What we want is a GUI client that our
developers can use to manage their own working copies, and the GUI
should run on the local workstation, like all the other GUI apps they
use. The problematic situation is the fact that the working copy has
(because that's how web-based projects with large databases work best)
to live on a machine that's different from the machine where the
Subversion GUI is being used. But with a little thought, this problem
can perhaps be solved by a Subversion GUI, and does not necessarily
need to be solved by the Subversion libraries.
On 25.01.2005, at 00:46, Toby Johnson wrote:
> One way you could accomplish this is to use Novell's NetDrive to mount
> your FTP site as a drive letter on Windows. Then use TortoiseSVN on
> that mounted FTP site. It will be rather slow and cumbersome for large
> projects, but it works.
We will use a solution like this. We'll actually use Samba shares,
since that's already set up. (I hope Samba's lack of symlink support
won't be a major problem, since most of our projects don't use
symlinks.) So for us there is not much of a problem. We can use any
Subversion GUI and tell it that the "local" working copy is in fact on
the Samba share.
> I don't understand how your developers will modify these files once
> they're checked out, though.
I think his developers will configure Dreamweaver's site settings to
indicate that the site is located at a particular FTP location, which
is the working copy in that user's home folder on the development
server. So I think the comment is that if his web site development
package can talk over FTP, then it would be nice for a Subversion GUI
to have the same ability. But, as I'm realizing, this is probably a GUI
feature and not a library feature.
> I think a better solution would be to figure out how they can test
> locally-made changes. Is there a reason they couldn't run local
> instances of Apache?
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.
\r
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 19:44:39 2005