[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion GUI client?

From: Toby Johnson <toby_at_etjohnson.us>
Date: 2005-01-26 20:03:33 CET

Ryan Schmidt wrote:

> 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.

No, you are making a very broad generalization here. Subversion works
plenty well for many PHP/MySQL projects; you are placing many extra
constraints on your workflow which many people don't agree with.

> 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.

The web site needs to have *a* working copy (or exported filesystem);
this doesn't mean that all developers must work in that same working
copy. Most people find this sort of setup very frustrating to use,
because it's impossible for one developer to isolate his changes from
the others'.

Also, any changes made to that one working copy affect *everyone* in
real-time. If one developer leaves a bug in his code and leaves for the
day, no one can get their work done until he fixes it.

> 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.

They don't all need to learn the command line. The administrator (you)
needs to know how to either update the server's working copy when
changes need to be pushed forward, or else write a hook script to
automatically update that working copy when commits are performed.

> 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.

So what happens if two different developers try to FTP their changes at
the same time, and they have both modified the same file? You'll never
know exactly what was lost or whose changes stepped on whose. These are
exactly the problems that a version control system is meant to solve,
and you're bypassing all these benefits by insisting on a single shared
working copy.

> 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.

Apache takes about five minutes to set up on Windows. Their installer
creates the service and everything. And I believe Mac has it built in.
You could maintain a central httpd.conf that everyone uses (well, one
for each platform), and keep all the extra modules and executables in a
central location as well. The other option would be to give everyone
their own development area on the server, and have your single Apache
installation set up to allow testing to all these different development
areas (should be pretty simple as long as you keep everything under the
same parent directory).

Again, having a shared working copy for everyone is definitely doable,
but most people find that the problems associated with it far outweigh
the benefits, and this is why you're having trouble finding tools which
explicitly fit your model.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 26 20:09:30 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.