I was apparently not as clear as I had intended. ;-)
On 26.01.2005, at 20:03, Toby Johnson wrote:
> Ryan Schmidt wrote:
>
>> 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.
I am in complete agreement with you. I should have been more precise
and written "The fact that it's a web site means that each developer's
working copy needs to be on a web server" so that developers can work
independently and test their own code before commiting to the
repository. We fully intend that each developer has her own working
copy, or even multiple working copies.
>> 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.
We fully intend to have another working copy on the server which is not
modified by developers but which always mirrors trunk, through the help
of a post-commit hook. However, each developer will need to interact
with her own working copy by using some kind of Subversion client. This
is the interaction we are looking to ease.
>> 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).
The local setup is not as easy as you presume. We're a web design shop
with sites for dozens of clients. Virtual hosts can have many custom
entries. Document roots would need to be changed to fit client
workstations. PHP versions would have to be kept in sync, as would
versions of installed PEAR modules and other libraries. Replicating
gigs of MySQL databases and PDF documents is impractical, but projects
are programmed to expect these resources in certain places (for example
MySQL on localhost, PDFs in a directory relative to document root). And
parts of our sites are programmed to execute binaries at a Unix-like
shell, and I don't even want to guess how that'll behave if the server
OS is suddenly Windows. Furthermore, to be sure that the site will work
on the live server, it is imperative that the development server be as
identical in configuration as possible. This is most effectively
accomplished if there is one development server and if it is
administered by the same person administering the live server.
On 26.01.2005, at 20:08, Tom Mornini wrote:
> Ideal situation BY FAR is to have a web server PER DEVELOPER, with
> documents and applications in WCs PER DEVELOPER. DB per developer is
> ideal as well, but is sometimes too difficult to implement mid
> project.
My coworkers and I have put our heads together at length trying to work
out the way to have per-developer DBs as well but have not yet come up
with a satisfactory solution due to the size of the databases in
question. For our first forray into using Subversion, we've agreed to
version control only the PHP text files and related items, and keep a
single central database -- or maybe one database per branch -- and
accept the corresponding limitations. But we hope to later move to a
model where a developer can indicate at checkout time whether she
intends to make a database change, and if so, receive a private copy of
it where she can test her changes. She manually records her changes as
SQL statements in a text file, and commits this along with her code
modifications. And somehow [1] these SQL statements then get applied to
the main development version of the database, and when the time comes
to update the live server, the change would occur there as well.
\r
[1] http://www.driedger.ca/classics-2/Image142.jpg
---------------------------------------------------------------------
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:43:42 2005
