RE: Module aliases

[Jim.Hyslop]

address@hidden wrote:
> Thanks a lot... this is getting much closer to what I need 
We'll get there eventually ;-)

> Ok, let me show this with a full example, seeing whether I understand 
> completely what you said above:
[...]

> So, what you are saying is that I should move all directories 
> to other 
> subdirectories under /cvs so that now, my cvs tree looks like:
> cvs
>       |_project_files
>               |_aa (file under "project")
>               |_bb (file under "project")
>               |_cc (file under "project")
>               |_dd (file under "project")
>               |_ee (file under "project")
>               |_ff (file under "project")
>               |_gg (file under "project")
>               |_ (... files, etc...)
>       |_project_a_b 
>               |_a (directory with files and subdirectories)
>               |_b (directory with files and subdirectories)
>       |_project_c_d_e
>               |_c (directory with files and subdirectories)
>               |_d (directory with files and subdirectories)
>               |_e (directory with files and subdirectories)
> 
>   ... (removing the "project" directory completely).
> 
> Then create entries in the modules file as follows:
> project_a_b -d project project_a_b
> project_c_d_e -d project project_c_d_e project_files
> project &project_a_b &project_c_d_e
Yes, that should do it. Try it out first, though, in a test area of your
repository, so you can fine-tune the details. If you don't have a
/cvs/cvs-test directory (and corresponding module), create it - it comes in
very handy for experimenting with various CVS commands. Make your mistakes
in cvs-test, so that your real, valuable repository never gets corrupted.

> An issue that I see with the final module line is this (from 
> 'info CVS' at 
> Ampersand modules node):
> "There is one quirk/bug: the messages that CVS prints omit the
> `ampermod', and thus do not correctly display the location to which it
> is checking out the files"
> 
> Have I got this right?  Does this mess up anything in CVS 
> that counts on the 
> "project" directory existing under /cvs?
OK, one concept you haven't quite got yet (maybe nobody's explained this) -
CVS knows nothing about "directory structures". It works on one directory at
a time, and has no clue where that directory exists in relation to its
parent directories, sibling directories or child directories. While CVS is
processing a directory, as far as it's concerned that is the only directory
that exists in the entire universe. This means the directory structure
inside your repository can be completely different from your checked-out
structure, and CVS doesn't care or even notice.

> What about the log entries, etc?? 
Log entries, etc. are stored within the repository file itself, so it
doesn't matter where the file is in the repository. The history and versions
will remain intact.

> How do I hide these changes from the users so they don't see 
> the structure of 
> the /cvs directory?  That is, I don't want users to see 
> something like 
> "project_a_b" ever, only "project".
When the files have been checked out, their local directory listing will
show only the directories project, project/a, project/b, and so on. The
entire process will be invisible to them (except for the brief time when
they'll have to clear everything off their local drives, then check it out
again).

The quirk mentioned above applies to the progress messages CVS displays,
while it is processing commands. Warn your users beforehand to expect the
output messages to change slightly.

If your users freak out about the project being broken up like this, tell
them to think of the repository like a warehouse. Each directory is a crate
that is stored inside the warehouse. Managing the exact storage location of
each crate is up to the warehouse manager (you, the cvsadmin) and the
warehouse workers (CVS). The crates will usually be all located in the same
area, but sometimes they will be scattered throughout the warehouse. Your
users don't know, and shouldn't care. What's important is, when the users
bring their truck to the shipping dock, they get all their crates back in
good condition, with their contents intact.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)