Hawke, that sounds pretty darn thorough to me.
On a single ACS Tcl project, you can get away with 4 or 5 developers
all working with the same Dev database, and in fact working in a
single shared CVS checkout. This was our standard practice at aD.
It's simplicity is a major selling point.
I don't know what happens if you try to run multiple AOLservers from
multiple CVS checkouts, all pointing the same database instance and
username. I've never tried that, but I suspect it would cause
problems. I suspect that if you go with separate Dev CVS checkouts
and AOLservers, you'll probably want a separate database username to
go with each one.
As far as code/data cross-polination, well, I guess that depends on
what it is exactly you have everybody working on. Do have several
completely independent projects, that just happen to all be using
OpenACS? Or one really big web site, that all those developers are
going to be hacking on?
I don't remember how the aD toolkit team did things back in the ACS
Tcl days - maybe one of them will chime in. :)
At aD, once they went to ACS Java, both the toolkit team and all the
client project developers pretty much had to go to C-style one
devloper, one CVS checkout, one database username, because of the need
to compile and deploy code - but you're probably already plenty
familiar with that. In fact, lots of folks installed Oracle on their
laptops, etc., to get their own private and portable development
sandbox. This isn't that hard, but it probably means you want to give
somebody the job of maintaining some sort of canonical test data set
(either an Oracle export or perhaps better, scripts to generate the
test data) that developers can easily re-load into their private
databases at will, to make it really easy for them to always be
writing SQL against realistic data.
One side benefit of having everybody run Oracle, AOLserver, ACS,
etc. on their own PCs is everybody learns how to run all that stuff,
by necessity. Of course, the disadvantage is that everybody spends
time learning to run all that stuff, by necessity... :)
I've never fooled with ACS subsites so I can't say much about how
they're useful for development. But I'm pretty sure all the Tcl
libraries for each package are sourced on a package level,
not package instance (subsite) level, so in practice, you're going to
have to give all the developer's site-wide-admin to this single shared
ACS Dev instance, let them install and un-install packages, etc.
Also, keep in mind that while it's hugely useful, the nifty "reload
all my Tcl library files for this pacakge" link you can click from
/acs-admin/apm/ is not 100% equivalent to simply restarting
AOLserver. In particular, if you spawn off a detached thread it gets
a copy of the Tcl libraries as they existed at the time AOLserver
started up, not as they've since been modified. (This is generally a
trivial problem as long as you know about it, as explicitly
spawning off new threads is not a common thing to want to do, and even
with the vast amount of ACS 4.2 Tcl code to source, restarting
AOLserver only takes 5 seconds or so.)
