Forum OpenACS Development: Response to Best way to setup dev env for many developers?

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