Author: Ville

In my post few days ago I discussed automatic working copy updating with CVS on Windows. Since then I’ve slightly fine-tuned the process. For one, I added a “-C” switch to the update (in case someone messes with the online files they will be clobbered on next update). I’m also undecided with “-P” to prune empty directories, and not quite certain about how it behaves with “-d” to create unexisting directories to the working copy.

Currently my automated update line in cvsuatoupdatebe.pl looks like this:

@args = ("c:/Program Files/CVSNT/cvs.exe", "update", "-C", "-d");

—

On an unrelated note… few days ago I had to capture a SMTP session between a CF script and a SMTP server. While there may be other (easier? :)) ways to do it, I came across a great open source application, Ethereal: A Network Protocol Analyzer. It has a handy “Follow TCP Stream” feature which reconstructs the conversation on a specific TCP thread. Additionally you can filter by IP, by port, etc. I configured it to record port 25 activity (this is on the client), started capture, ran the script, stopped capture, chose the target IP from the list, and selected “Follow TCP Stream” and in an instant had the SMTP session I was looking for.

While on UNIX it’s at least functionally possible to have the auto-updated “working” files in the same folder with the CVS versioned files, it’s generally not a good idea, especially if the files sit on the web without a password. When viewed through a web browser the versioned files are printed as ASCII. If the location is not password protected the web users can read contents of your server side logic files (php, cfm, asp, jsp, etc.). On Windows there’s also conflict with the CVS folder which eventually (when attempting to update subfolders) leads to anomalies if bypassed.

I initially toyed with the idea of placing the versioned and working files into the same folder, but soon realized it’s the best to put the versioned files into their own, non-web-accessible folder, and have the CVS auto-update the working files in a web-folder (which you may want to password protect via your web server configuration).

I’m working on a ColdFusion project in a small team, and wanted to take advantage of CVS to prevent editing same files at the same time. Because of the nature of the project the components could not be tested on local systems, and recreating the actual .cfm, .cfc, .xml, etc. files after every edit didn’t seem very much fun. I had previously used CVS on UNIX side and knew that autoupdate would be possible. However, to get it running on Windows required some extra steps.

On the UNIX side all that is needed is that you check out a working copy to the repository (or other) folder which is accessible under web root (so that you can test the files via the web server), and then add something like this to the loginfo:

ALL ((cd /path/to/repository/module; cvs -q update -d) &) >> /dev/null 2>&1

The ampersand (inside the parentheses) forks the process and thus cicumvents the problem with CVS repository locking. Whenever a commit is made, the update is run, and you can view the latest files via the web browser.

BUT on Windows this doesn’t work. I initially wrote a small batch file like so:

e:
cd e:pathtorepositorymodule
"c:Program FilesCVSNTcvs.exe" update -d

… and initially thought that it works. But it soon dawned on me that the update was always one version behind the current. That’s because the current version was still locked by the CVS when I called the batch file from loginfo.

Lots of searching on the web ensued. Finally, I came across Jouni Heikniemi’s website on »CVS: Using loginfo to send mail with diffs on Win32/CVSNT». While I did not need the diff/mail functionality, the core problem was the same: how to bypass the CVS file locking in Windows’s threaded environment? Jouni had solved the problem by creating two Perl files, one of which is called from loginfo, and the second one is subsequently called from the first one, thus spawning a new process that waits around for a few seconds for the CVS locks to be released, and then performs the update.

I adapted Jouni’s Perl files for the purpose of auto-update. The resulting files are extremely simple.

cvsautoupdate.pl:

#!c:/perl/bin/perl -w

# Spawn another process to avoid CVS locking. 

# Construct the path to cvsautoupdatebe.pl
$autoupdatepath = "e:/inetpub/cvstools/cvsautoupdatebe.pl";

# Call the system command interpreter and start a new process
system($ENV{'COMSPEC'}, '/c', 'start', $autoupdatepath);

and cvsautoupdatebe.pl:

#!c:/perl/bin/perl -w

# Wait for a moment so that the main (calling) CVS task finishes 
# and releases repository locks. Then run update.

sleep 5;

chdir "e:/inetpub/wwwroot/cvsdev/viaproject" 
	or die "cd failedn";

@args = ("c:/Program Files/CVSNT/cvs.exe", "update", "-d");

system(@args) == 0 
	or die "system @args failed: $?";

(I realize the Perl code could probably be more eloquent, but Perl is not my forte, and this works. :))

Now I simply call the first file from loginfo with…

ALL c:/perl/bin/perl e:/inetpub/cvstools/cvsautoupdate.pl

.. and when a commit is made, within few seconds the resulting files are updated as well, and I can hit refresh on my web browser pointing to the development directory to see whether the edit produced the desired result.

By the way, this all pertains to cvsnt! Client, on the other hand, can be anything that supports cvs. Eclipse, of course, is a nice IDE, but for many smaller projects TortoiseCVS is perhaps more suitable (it’s lighter, and you can use any editor you like.. like UltraEdit :)).

If I have gone out of my way to do do something very simple in a very difficult way, please feel free to comment!