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...
8 comments:
Hi, I caught sight of your blog via the cvsnt mailing list. Interesting content. Unfortunately I don't have an answer for you on the modules2 question. I look forward to more posts about agile development, automation, and your build system. Keep up the posts!
Thanks for the comment! We've taken sooooo much from the Agile community....just wanted to give something back.
I tried using modules2 well over a year ago and gave up because it was buggy and undocumented.
As far as I can see nothing has been done to address either of those two things.
Ahh modules2, I would say I miss them, but that wouldn't be completely true. I like to think of alias modules like reports: They're great for viewing and using data, but it's not where you input data. Reason is most reports don't tell you the exact origins of the data, and alot of times are displayed outside of their original domain, so where would you put any new data?
If an alias module is nothing more than displaying 4 out of 5 subfolders in an existing module, would any new module be added as a subfolder of that module?
The problem is it's origins are abstract which making any management, like you said, scary.
I wonder if you can help me, both poster and commenters, if you have some experience with modules2
My problem is I want to use the modules2 file to create "views", but I am having difficulty. I can't figure out how to pull off this scenario:
I have a module (Module1) with the following root folders (each root and subfolder has various files and subfolders):
DeckWebs
ExternalServices
The DeckWebs is all web code, meaning the code/source file IS the output (what goes to the web server)
The external services are c++ files that get compiled to output (dlls)
I want a "view" so the build team can just get that "view" and not wonder what get sent out (I know, they should know, right?)
So I tried this:
[WebServerView]
DeckWebs = Module1/DeckWebs
WebServices = Module1/ExternalServices (^*asax$|^*asmx$|^*config$|^*dll$)
My goal was to get everything in DeckWebs and just the four file types you see here in WebServices, recursively through each subfolder.
This way, the build team would just checkout (export for release, we use TortoiseCVS) the WebServerView alias and be on their way.
Thank you for being a resource and posting your thoughts. I feel the modules2 file isn't documented enough for me to grasp it yet. I thought this task was simple but apparently it isn't?
Thank you for your time
wait, doh... i think the problem here is my regular expressions suck (learning two things at once). Sorry to bother, I think I am on my way. This is a great blog. I stopped to peruse some other things and learn from your experience.
Thanks for the comment...haven't gotten that deep into modules2 before. Did you come up with a solution? If so please share with us ;)
If I come up with one that works I'll be sure to post it.
Thanks! Really good content with a great idea. http://sidingcontractorvictoriabc.com/
Post a Comment