In a previous environment that I worked in, we used CVS to handle the concurrent development updates. We had an automated process that did pushes from CVS fixes branch into production every morning. For critical fixes, there was also a manual scripted way to push changes immediately into production. Any large scale development would be in a CVS dev branch that would be synchronized with the fixes branch periodically. This was the ideal situation for us. People that needed to push changes into production immediately could while people that wanted/needed/were required to have their changes QA'ed could have that done as well. And then depending on the branching structure, we could have an area for long-term development. Dean Warden, Matt writes: > > to confirm, yes, i do have all the passwords from dan, but contrary to > > rumour, all i can do is access the production database -- you do not want > > me even attempting anything else (image of child playing with matches) > > > > despite the necessity (or convenience) of touching live stuff, which has > to > > happen from time to time, i think we should try to get a good test > > environment (site plus database) going > > > > who can help us get there? if anybody else feels like i do, let's take > > this over to thesite > > If anything, it would be easier to have changes like mine in a central > place. > > Plus, I could integrate my changes with the dynamic file rather than having > dan or someone else do it. > > But, this would probably only be a testbed for the w.e.o site, right? Oh > well. Still a good thing, IMO. > > We would have to address keeping the t.e.o version current, tho. Especially > with *cough* certain people *cough* making changes directly to the w.e.o > site. =P > > If we get this set up, I'll insert some test data, etc. I have a local > version of thesite, but it's a little outdated. > > > Thoughts?