[cvsnt] Repo/Module setup suggestions and how to use CVS for web development question?

John Peacock jpeacock at rowman.com
Fri May 9 16:12:44 BST 2003

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 sales@march-hare.com.

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:


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.



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook