Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Bo Berglund wrote:
> 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.
FWIW: I never had to use ampersand modules so far. At the time when I
was constructing our modules definitions, comments on this list
indicated that ampersand modules were chronically bugged so I steered
clear of them (and as a side-effect, never really got the hang of them
either). This might have improved in the meantime but now our modules
file is alive and kicking and it doesn't seem to miss anything w.r.t.
functionality that ampersand modules might potentially offer.
> 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)
Does it? That would indeed be slightly cleaner than my approach of
combining regular and alias modules. You seem to get around specifying
one additional folder level ("MyProject" in this case). Might make
definitions more versatile in some situations too. Maybe I'll give
ampersand modules another shot after all for our next project...
> Is it true that this structure can only be achieved after all of the
> source modules have been created and populated?
Not sure what you mean... I think an operation on a virtual module
would abort if one of the referenced modules does not exist (yet) if
that's what you're asking...
> Can the developers add a folder in his Common/Include folder and it
> gets created in the INC/Incl folder on the server?
Yes. It does not matter what the folder is named in the sandbox. The
only thing CVS takes an interest in is the name stored in the
./CVS/Repository file.
> What happens if one browses this server with ViewCvs? Will it grab and
> show the virtual modules as well as the physical ones?
No, I don't think so. That is probably only possible when using the
modules2 file. However, ... see below.
> 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?)??
Well, as I stated before, I'm working in a very small team and am thus
probably not a very good showcase for this question. Roughly 75% of our
repository activity is caused by me alone if not more. Thus I'm also
the only one managing the modules file.
> What advantages does modules2 give here?
As has been discussed twice already this week, very little ranging on
none at all. A lot of the time it is not really possible at all except
for a few (IMO) less useful cases.
Actually your above example might even work using modules2 if
"MyProject" is really the name you want the top-level folder of the
checkout to be named and if there is no other root-level module
(physical or virtual) of that name already. I think something like this
would do (untested):
[MyProject]
Common/Include = INC/Incl
Common/Classes = CMN/Classes/SomeClasses
Src = PRJ/MyProject/Source
Bin = PRJ/MyProject/Bin
Note that in modules2 it is not possible to define more than one module
with the same potential (relative!) target location as is possible with
the old modules file (obviously in that case you wouldn't actually
check these out simultaneously into the same spot). Every module name
you define in modules2 will effectively become a (virtual) root-level
folder in your repository (also when browsing with cvs ls) and thus has
to be unique. Old modules names have to be unique as well but in
contrast to modules2 that has no effect on the uniqueness requirement
of their defined checkout targets. E.g. I have a modules definition for
one of our third party libraries which comes with sources both for
Delphi 5 and Delphi 7:
SomeLib5 -d SomeLib/Src External/SomeLib/D5/Src
SomeLib7 -d SomeLib/Src External/SomeLib/D7/Src
This is not possible with modules2 AFAICT or at least I wouldn't expect
it to produce sensible results.
You also couldn't checkout multiple modules into the current working
folder in one go. There would have to be an intermediate root folder,
i.e. where with the old modules you could do this:
MyModules -a ModuleA ModuleB ModuleC
..and on checkout would get ModuleA, B and C right into your working
directory, the following seemingly equivalent modules2 definition would
create an intermediate folder named MyModules in your current working
folder into which the three modules will be placed:
[MyModules]
ModuleA
ModuleB
ModuleC
> 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?
Tony has already stated that modules2 is not intended for grouping
files under symbolic names. It is for masking the structure of the
repository. I guess you could view modules2 definitions as something
like hard links.
Hope this helps.
--
Oliver
---- ------------------
JID: ogiesen at jabber.org
ICQ: 18777742 (http://wwp.icq.com/18777742)