On Nov 5, 2007, at 21:16, Joseph Koenig wrote:
> I'm wondering how everyone else has their development / test
> environment set up. We're doing LAMP type development work, with
> all of the developers working on Mac OS X workstations. We've got a
> CentOS 5 development server that is used for testing. I'm not a
> huge fan of the way that each workstation has to have Apache and
> PHP installed in order to work locally. It seems difficult to
> ensure everyone has the same version of everything, same
> extensions, etc...
>
> So, here's my ideal world situation of what would happen...
>
> Each developer would have a network drive - through NFS or Samba.
> This drive would be on the development server itself. Through
> ZendStudio, the developers would checkout a copy of the project to
> their network drive. So, essentially, it would just checkout a copy
> to their specific workspace on the CentOS server. Apache would be
> setup with each developer having their own workspace, for example, /
> www/userName1, /www/userName2, etc. The httpd.conf file would
> simply allow them to create userName1.domainname.com, etc. Then,
> when done working, they would just commit their files back to the
> repository. This would ensure everyone was using the same version
> of Apache, PHP, etc.
>
> Has anyone else done anything like this? If so, any tips? Is this a
> crazy idea?
Yes, I've done that. The downsides were that there was some weird
interaction between the Linux Samba server and the Mac OS X Samba
client, such that I couldn't use any Subversion commands on the
remote working copy if I tried to execute them from my Mac. I forget
the exact error, but to work around it I always had to ssh to the
Linux machine and perform the svn commands locally on the Linux
machine. I was the only Mac user and I didn't mind, but others might
mind, especially those who would rather use GUI tools than the svn
command line.
Various svn operations were also slower in this setup because
everybody's working copy was on one computer, sharing its hard drive
and disk cache resources. It's quicker if the working copy is on your
local machine, and when you work on it, its info is loaded in your
disk cache, and hopefully stays there while you're working on it,
instead of getting flushed out just because somebody else does an svn
operation across another big working copy.
The shop where I worked deemed this an acceptable solution, and
better than installing Apache and PHP and MySQL on every developer's
(Windows) box. But it doesn't have to be difficult, especially not on
a Mac or Linux machine. Just use a package manager to keep the
software up to date. On the Mac, I recommend MacPorts. You can
install Subversion, Apache 2, PHP 5, and MySQL 5 quite simply:
sudo port selfupdate
sudo port install apr-util +no_bdb
sudo port install apache2
sudo port install subversion +mod_dav_svn +tools +no_bdb
sudo port install mysql5 +server
Keeping the software updated is easy:
sudo port selfupdate
sudo port upgrade outdated
Note that you should stop your services (apache2, mysql5) using
launchctl before they get upgraded. You can start them again after
the upgrade is done.
You could probably write a simple update script to handle all of
this, and make it run thru cron (or, better yet, Launch Services)
late at night, or over the weekend, while your developers aren't
working.
You may want to consider whether you want the MySQL databases on the
local developer machines, or whether it would be acceptable to have a
single shared development database on a central server. The latter
could be easier, but does leave some room for problems (such as
someone removing a column which is no longer needed in their local
code, but which is still needed by everyone else's working copy...).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 6 22:34:44 2007