CVS: Modules vs Subdirectories

Does anyone know what is the best approach to define structure of modules/directories in CVS? Specifically what if I have big project that could possibly has many sub-projects (even not related). Is it better to define module for each sub-project or use subdirectories:

1. Approach #1 Modules

   • CVSROOT
     • Main Project
     • Platform A Sub-project1
     • Platform A Sub-proj开发者_如何学编程ect2
     • Platform B Sub-project3
     • ...

2. Approach #2 subdirectories

   • CVSROOT
     • Project
       • Main
       • Platform A
         • Sub-Project 1
         • Sub-Project 2
       • Platform B
         • Sub-Project 3
       • ...

From the user and check-out end, you can't tell. I have even mixed and matched. Basically, if it finds it in Modules, it uses what Modules says, but if not, it assumes it is a sub-directory and tries that.

The one real advantage of modules is that the client can list the modules, before checkout, which can be nice and useful. If you already have sub-directories, and want to add that functionality, though, you can add them to the modules file so that they appear in the same place in the tree, though.

If there are projects, especially not related to main one - I would go with creating modules for each of them. Try to ask yourself - why you want to group everything, even not directly related things into one space? Would it be not more structured to have things separated?

A little off-topic experience, but may be still useful: sometimes also having separate modules are easier to manage in IDEs. E.g. Eclipse. I have experience with both ways - and having each project as separate module - makes tags management easier later - to tag/browse existing tags...

I mix and match.

E.g. I CVS'ed my home directory for circa 20 years. (Now I use hg and/or git.)

Not just my home directory, but many different projects and tools. Unrelated, except for the fact that I worked on them. All of which live under my home directory, in places like ~glew/src

Subdirectories are less overhead to maintain.

Modules are what you need if you need to assemble several subdirectories into a single logical module.

E.g. some of my tools live in places like ~/src/tool1, ~/src/tool2.

Some of them share common stuff ~/src/my-lib

I don't want people to have to checkout all of ~glew/src just to use ~/tool1. I.e. I want them to be able to checkout just tool1, and to get everything they need by doing so. I don't want them to have to checkout ~/src/tool1, and then ~/src/my-lib, and then ~/src/my-lib2...

So I create a module using &, so that when they checkout tool1, they also get ~/src/my-lib instantiated as tool1/import/my-lib. And so on.