CVS modules
Toralf Lund
read the answers, if any, before they expired because I was on
holiday...
My question is simply: Using CVS's "modules" mechanism or otherwise, how
do I:
1) Define a subset of the directories in my CVS repository as a logical
module.
2) Define super modules consisting of other modules or a mixture of
modules and directories.
3) Describe the inter-dependency or logical order of directories and
modules.
(I do not want to have a separate directory for each high level module,
for various reasons.)
I have tried editing CVSROOT/modules, of course, but with limited
success. In particular, my entries seemed to have an effect only for the
"checkout" command; passing one of the new module names I defined to
"checkin", "update" etc. resulted in a "nothing known about ..." error
message.
--
Toralf Lund <tor...@advim.no> \ "Ellers var der intet." \
\ Advanced Imaging AS \ \
\ Billingstad, Norway \ (Bjørnstjerne Bjørnson) \
\_Tel +47 66 98 26 55_________\____________________________________\
Ernst-Udo Wallenborn
> My question is simply: Using CVS's "modules" mechanism or otherwise, how
> do I:
> 1) Define a subset of the directories in my CVS repository as a logical
> module.
> 2) Define super modules consisting of other modules or a mixture of
> modules and directories.
> 3) Describe the inter-dependency or logical order of directories and
> modules.
> I have tried editing CVSROOT/modules, of course, but with limited
> success. In particular, my entries seemed to have an effect only for the
> "checkout" command; passing one of the new module names I defined to
> "checkin", "update" etc. resulted in a "nothing known about ..." error
> message. =
Hi,
i'm rather new to cvs myself, and have a similar problem and achieved
only a partial solution. Basically what i have is a project that's
split into several subprojects. They share common files and they should
be treated as logical modules, i.e.
project
Makefile
commonfile
sub1
Makefile file11 file12
sub2
Makefile file21 file22
where i want to be able to say 'cvs co sub1' and get just the logical
substructure necessary for sub1
project
Makefile
commonfile
sub1
Makefile file11 file12
My modules file currently has entries like this:
sub1 \
-d project/sub1 project/sub1 \
../Makefile ../commonfile \
Makefile file11 file12
and this works just fine for checkout. Hoewver, at checkin i have
to check in every modified file manually 'cvs ci file1', otherwise
i get:
cvs commit: Examining sub1
cvs commit: Up-to-date check failed for `sub1/..'
cvs [commit aborted]: correct above errors first!
and of course for every added file i have to add an entry in modules.
How do the pros handle this, really?
--
Ernst-Udo Wallenborn
Laboratorium fuer Physikalische Chemie
ETH Zuerich
Jochen Hollmann
CVS seems to think only forward. ".." in a filename seems to be backward...
> and of course for every added file i have to add an entry in modules.
>
> How do the pros handle this, really?
Well, I'm not a pro, but I have a (simple) suggestion for the modules file:
project project
sub1 sub1
sub2 sub2
proj1 -d project project &sub1
proj2 -d project project &sub2
You checkout proj{1,2}
or if you want to keep the whole stuff in one directory in $CVSROOT
and have no name conflicts, you can try:
project project/common &ABC &XYZ
ABC -d sub1 project/sub1
XYZ -d sub2 project/sub2
sub1 -d project project/common &ABC
sub2 -d project project/common &XYZ
In this case you can checkout sub1{1,2}
Be aware, that cvs import takes a path relative to $CVSROOT and not a
module name...
BTW: I used CVS 1.9
Cheers,
Jochen
--
Jochen Hollmann, CHIPS DCE/DFS System Developer
Chalmers Technical University, Gothenborg, Sweden, Europe
Toralf Lund
instance) "cvs commit sub1"?
>
> Be aware, that cvs import takes a path relative to $CVSROOT and not a
> module name...
>
> BTW: I used CVS 1.9
>
> Cheers,
> Jochen
>
> --
> Jochen Hollmann, CHIPS DCE/DFS System Developer
> Chalmers Technical University, Gothenborg, Sweden, Europe
--
Ernst-Udo Wallenborn
That's what the '&' is for! I couldn't figure out what the
'You can encode a module within a module...' meant.
> You checkout proj{1,2}
> or if you want to keep the whole stuff in one directory in $CVSROOT
> and have no name conflicts, you can try:
I liked the second idea better, and finally chose something very similar.
Now my modules file looks like this
project project \
Makefile commonfile &sub1 &sub2
proj1 -d project project \
Makefile commonfile &sub1
proj2 -d project project \
Makefile commonfile &sub2
sub1 -d proj1 project/proj1
sub2 -d proj2 project/proj2
and that does just what i want. I can say 'cvs co proj1' and get
exactly the substructure belonging to proj1 and the update problem
at checkin has vanished.
Thank you very much.
Jochen Hollmann
> Jochen Hollmann wrote:
> [...]
> > or if you want to keep the whole stuff in one directory in $CVSROOT
> > and have no name conflicts, you can try:
> >
> > project project/common &ABC &XYZ
> > ABC -d sub1 project/sub1
> > XYZ -d sub2 project/sub2
> > sub1 -d project project/common &ABC
> > sub2 -d project project/common &XYZ
> >
> > In this case you can checkout sub1{1,2}
> This is all very fine for checkout, but what happens if you do (for
> instance) "cvs commit sub1"?
Well, CVS is not very consistent in the use of either module or directory
names. Some times like on checkout time you can/should use module
names. Sometimes you cannot - like when you commit.
This is not a fault of CVS, it's more of principal nature: You are allowed to
checkout more than one copy of the same module into different
directories... How should CVS know what to commit if you say
"cvs commit sub1"??
BTW the manual says:
cvs commit *FILE*...
Use this command when you wish to ``publish'' your
changes to other developers, by incorporating them in
the source repository.
So for my above example module file the you would do:
cvs co sub1
# [[ hack away ]]
cvs commit project (assuming that you are standing in the same directory
as at checkout time).
BTW, I would not consider this the normal way to commit things. Either you
stand in the directory project and just say "cvs commit" to commit all your
changes or - what I would recommend - do the commits in each directory giving
the exact FILENAMES. This way you avoid checking in changes you may have made
earlier and just forgot about them...
You should also recognizes, that you get a "problem" checking out sub1 and
sub2 into the same directory, if you commit your changes in one shot. The
"problem" will be that you commit the changes from module sub1 as well as
from module sub2!
Cheers,
Jochen
PS: Actually you could say "cvs commit sub1" if you change the module file a
little bit. But I leave this as an exercise... Just play a little bit around
with the already used concepts and note that sub1 would not be used as a name
for a module...
Ernst-Udo Wallenborn
Jochen Hollmann <jo...@robbie.chips.chalmers.se> writes:
> This is not a fault of CVS, it's more of principal nature: You are allowed to
> checkout more than one copy of the same module into different
> directories... How should CVS know what to commit if you say
> "cvs commit sub1"??
there's a lot of automagic filenamemapping going on in cvs
(i noticed that whe i tried to use cvswrappers for the first time
and had to -t-track to get that working), and that's basically
the only way cvs can get the done, i agree.
> So for my above example module file the you would do:
> cvs co sub1
> # [[ hack away ]]
> cvs commit project (assuming that you are standing in the same directory
> as at checkout time).
i'd rather do
cvs co sub1
cd project/sub1
[hack away]
cvs commit (in the sub1 directory)
granted, this can be done just as easily with cvs co procject;
cd project/sub1, but somehow the way above seems to be cleaner to me.
If you want to work on sub1 you should only see sub1 (and of
course all common files it needs).
> You should also recognizes, that you get a "problem" checking out sub1 and
> sub2 into the same directory, if you commit your changes in one shot. The
> "problem" will be that you commit the changes from module sub1 as well as
> from module sub2!
Well in my case it's rather the rule that i work only on one
subproject at a time, yet want to commit to a common release tag
for the whole project every once in a while. So this problem
won't occur.
> PS: Actually you could say "cvs commit sub1" if you change the module file a
> little bit. But I leave this as an exercise... Just play a little bit around
> with the already used concepts and note that sub1 would not be used as a name
> for a module...
I think i have it working now the way i wanted it in the first place.
Thanks, you've been very helpful.