有谁知道在 CVS 中定义模块/目录结构的最佳方法是什么？具体来说，如果我有可能有许多子项目（甚至不相关）的大项目怎么办。是为每个子项目定义模块还是使用子目录更好：
方法 #1 模块
方法 #2 子目录
【问题讨论】：
标签： cvs
从用户和结帐端，你无法分辨。我什至混合和匹配。基本上，如果它在 Modules 中找到它，它会使用 Modules 所说的内容，但如果不是，它会假定它是一个子目录并尝试这样做。
模块的一个真正优势是客户端可以在结帐之前列出模块，这非常有用。但是，如果您已经有子目录，并且想要添加该功能，则可以将它们添加到模块文件中，以便它们出现在树中的同一位置。
【讨论】：
如果有项目，尤其是与主要项目无关的项目 - 我会为每个项目创建模块。试着问问自己——为什么你想把所有东西，甚至不直接相关的东西放在一个空间里？把东西分开不是更有条理吗？
有点离题的经验，但可能仍然有用：有时在 IDE 中也更容易管理单独的模块。例如。蚀。我有两种方式的经验 - 并且将每个项目作为单独的模块 - 使标签管理以后更容易 - 标记/浏览现有标签......
【讨论】：
我混搭。
例如我 CVS 保存了我的主目录大约 20 年。 （现在我使用 hg 和/或 git。）
不仅仅是我的主目录，还有许多不同的项目和工具。无关，除了我在他们身上工作的事实。所有这些都在我的主目录下，在 ~glew/src 之类的地方
子目录的维护开销更少。
如果您需要将多个子目录组装成一个逻辑模块，则需要模块。
例如我的一些工具位于 ~/src/tool1、~/src/tool2 等位置。
其中一些共享共同的东西 ~/src/my-lib
我不希望人们为了使用 ~/tool1 而必须检查所有 ~glew/src。 IE。我希望他们能够只签出 tool1，并通过这样做来获得他们需要的一切。我不希望他们必须检查 ~/src/tool1，然后是 ~/src/my-lib，然后是 ~/src/my-lib2...
所以我使用 & 创建了一个模块，这样当他们签出 tool1 时，他们也会将 ~/src/my-lib 实例化为 tool1/import/my-lib。以此类推。
【讨论】：