Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
Bo Berglund wrote: > You should program the postcommit script file to do the "shadowing" > out to the 'production' server so it will duplicate all committed > files to this server automatically. Then the production server will > only have code that has been deemed OK by the developer. NO!!!! The production server should _never_ be automatically updated. This is just asking for trouble. The development server can be automatically updated, so if something breaks, so what! To respond to the original poster now: Samuel Neff wrote: > Web Development > > The issue is that all developers share one development server. Our initial > thoughts are to use CVS as our repository for ColdFusion files and set up > CVS to automatically copy files from the repo to the webroot on each > check-in. VSS called this shadowing, and I think I saw some utility for > CVSNT to do this. In the modern CVSNT, you can use the postcommit file to keep the development server in sync. I have a somewhat crude script to do this; I hope to have time to make it more robust and easier for others to manage, but it works like a charm. > > The problem one developer pointed out is that while developing CF apps we > will need to commit the files just to test them, not when we're done. This > will result in probably as many as a few dozen commits per day per developer > for each file they're working on. The history will grow large and it'll > make finding older versions difficult. So what! You should never rely on the history file to locate versions in practice; it is just there to perform detailed analysis if required. You should get into the mindset of "Commit Early, Commit Often" and get over the concern of having lots of changes. Once you have a stable version, use the ability to force a new version number to bump the revision for all associated files to the next major level. There are two basic ways to manage multi-developer access with web development: tags and branches. One basic assumption to be made is that most of the time, developers are working on their own things, and that only occasionally are shared files involved. If that is not true, there are a lot of social changes that are going to have to be made, so that people make a habit of updating and merging changes on a regular basis. You will also want to set up the commit e-mails and make use of watchers. My suggestion is to study the following sites: http://cvsbook.red-bean.com/ http://www.durak.org/cvswebsites/ specifically the former's chapter titled "Going Out On A Limb" which describes several models (I like the Flying Fish best). The HEAD branch should in practice always be stable, and this is what should be manually updated to the production site when ready. Each Project with independent files can be on it's own branch (you can easily move the sanbox of the Development server onto the branch you are testing). Share files are more difficult to handle (because of merging), but you can have those in their own branches and simply be more careful about managing them. HTH John