[cvsnt] Using modules to define "virtual modules"...

Bo Berglund bo.berglund at telia.com
Tue Jan 25 23:01:09 GMT 2005


I am now forced to bite the bullet and convert our entire CVSNT server
from 10 separate repositories to a single one with the old
repositories accessible as physical modules. This will require some
careful planning of course since there are a number of developers with
sandboxes out there.
We need this to handle the common files problem and the best way so
far is probably to have virtual modules defined and checked out. So we
need everything to be in one single repository of course...

But I have a question for those of you who have tried this avenue:
It seems to me (after some tests I have done) that the way to get a
decent looking checkout folder structure is to use ampersand modules.
Something like this:

#Defines for submodules
Includes -d Common/Include INC/Incl
MyClasses -d Common/Classes CMN/Classes/SomeClasses
MySources -d Src PRJ/MyProject/Source
MyBinaries -d Bin PRJ/MyProject/Bin
#Main project module
MyProject &Includes &MyClasses &MySources &MyBinaries

This would in effect define a checkout structure like so:
MyProject
  +-Common/Include (here go files from INC/Incl)
  +-Common/Classes (here go files form CMN/Classes/SomeClasses)
  +-Src (here go files from PRJ/MyProject/Source)
  +-Bin (here go files from PRJ/MyProject/Bin)

Questions:
Is it true that this structure can only be achieved *after* all of the
source modules have been created and populated?

Can the developers add a folder in his Common/Include folder and it
gets created in the INC/Incl folder on the server?

What happens if one browses this server with ViewCvs? Will it grab and
show the virtual modules as well as the physical ones?

How is the modules file managed by you who use it? In my case I need
someone else (preferably the developers themselves) to define their
module structures such that they get the proper files where they want
to have them. But this requires write access to CVSROOT/modules and
this is a single file defining everything, right. A screwup like a
duplicate name somewhere in this potentially big file will likely
cause big problems, right? So how do you handle this (Oliver?)??

What advantages does modules2 give here?
We would like a simple way to tag all relevant files for a project in
one go and to be abel to likewise commit all changes in one go as
well.
I think I read that something is not possible with modules2, but what
was that?


/Bo
(Bo Berglund, developer in Sweden)



More information about the cvsnt mailing list