CVSNT has an interesting feature not found in the generic cvs server...."modules2". I've been using this feature for quite some time. It offers some interesting options when compared to the standard modules feature in cvs (and cvsnt). I am not going to cover all of it's features since those can be found on the cvsnt web site....suffices to say that modules2 allows you to define alias modules in cvs using a sort of regex language of expressions.
For a long time I had my guys using modules2 strictly for checkouts done by our build server. We could wrap up all the dependencies in cvs under a single "alias" module. So far one downfall has been that modules2 modules don't support the history command :P Oh well, it still made managing dependencies easy. I've always shied away from letting engineers use modules2 locally because of potential issues with check-ins and creating new modules. Recently some of the engineers (myself included) have started working directly from modules2 sandboxes. It's actually scary. Where do the new modules you create get built? What contracted agreement ensures the behavior will never change? In general most other cvsnt functionality is well documented and has a great deal of precedence to fall back on....modules2 has neither and it may be a mistake to depend on it when it really offers little more than convenience.
We have run into some trouble. One tool we use, pushok, to integrate cvs into Visual Studio tried to create a new module at the root of the modules2 module. Nothing was actually created. Problem is, what should the behavior be? How should these tools behave?
Has anyone else had trouble with modules2? Am I over-reacting? Right now it's my intent to switch our build servers over to using flat module checkouts. This will bring back the history command and speed things up. I am going to discuss the use of modules2 sandboxes the team and try to achieve some sort of consensus.
Update on 3 Jan 2007
Well, I've gone threw and replaced our modules2 definitions with a set of batch files for checking out our various "sandboxes". The batch files look something like this:
SET CVSROOT=:sspi:cvs.foobar.com:/FOO
SET NEWMODULEPATH=FOO.BAR.ALIAS
mkdir %NEWMODULEPATH%
cd %NEWMODULEPATH%
cvs co -P project1
cvs co -P project2
cvs co -P foobar34
cvs co -P common/lib
cvs co -P common/src
So far it's working out pretty well! To check out a set of modules we just run our batch file! More to follow...
