Having setup literally hundreds of projects over the years, and having specialized in software configuration management and release engineering, I would recommend that you first focus on how you want to build/release your project(s).
If you only use an IDE to build (compile and package) your project(s), then you might as well just follow the conventions typical for that IDE, plus any "best practices" you may find.
However, I would strongly recommend that you do not build only with an IDE, or even at all. Instead, create an automated build/release script using one or more of the many wonderful open-source tools available. Since you appear to be targeting Windows, I recommend starting with a look at Ant, Ivy, and the appropriate xUnit (jUnit for Java, nUnit for .NET, etc.) for testing.
Once you start down that path, you will find lots of advice regarding project structure, designing your build scripts, testing, etc. Rather than overwhelm you with detailed advice now, I will simply leave you with that suggestion--you will readily find answers to your question there, as well as find a whole lot more questions worth investigating.
Enjoy!
Based on comments, it seems that some detail is needed.
A particular recommendation that I would make is that you separate your codebase into individual subprojects that each produce a single deliverable. The main application (.EXE) should be one, any supporting binaries would each be separate projects, the installer would be a separate project, etc.
Each project produces a single primary deliverable: an .EXE, a .DLL, a .HLP, etc. That deliverable is "published" to a single, shared, local, output directory.
Make a directory tree where the subprojects are peers (no depth or hierarchy, because it does not help), and do NOT let projects "reach" into each other's subtree--each project should be completely independent, with dependencies ONLY on the primary deliverables of the other subprojects, referenced in the shared output directory.
Do NOT create a hierarchy of build scripts that invoke each other, I did and found that it does not add value but does exponentially increase the maintenance effort. Instead, make a continuous integration script that invokes your stand-alone build script, but first does a clean checkout into a temporary directory.
Do NOT commit any deliverables or dependencies into source control--not your build output, not the libraries that you use, etc. Use Ivy against a Maven-like binary repository that you deploy separate from source control, and publish your own deliverables to it for sharing within your organization.
Oh, and don't use Maven--it is too complicated, obfuscates the build process, and therefore is not cost-effective to customize.
I am moving towards SCons, BuildBot, Ant, Ivy, nAnt, etc. based on my target platform.
I have been composing a whitepaper on this topic, which I see may have an audience.
发布评论
评论（2）
多年来，我已经建立了数百个项目，并且专门从事软件配置管理和发布工程，我建议您首先关注如何构建/发布项目。
如果您只使用 IDE 来构建（编译和打包）您的项目，那么您不妨遵循该 IDE 的典型约定以及您可能找到的任何“最佳实践”。
但是，我强烈建议您不要仅使用 IDE 进行构建，甚至根本不要构建。 相反，使用许多可用的优秀开源工具中的一个或多个来创建自动构建/发布脚本。 由于您似乎面向 Windows，因此我建议首先查看 Ant、Ivy 和适当的 xUnit（用于 Java 的 jUnit、用于 .NET 的 nUnit 等）进行测试。
一旦你开始沿着这条路走下去，你会发现很多关于项目结构、设计构建脚本、测试等的建议。我不会现在用详细的建议让你不知所措，而是简单地给你留下这个建议——你会很容易找到答案在那里找到你的问题，并找到更多值得研究的问题。
享受！
根据评论，似乎需要一些细节。
我提出的一个特别建议是将代码库分成单独的子项目，每个子项目生成一个可交付成果。 主应用程序 (.EXE) 应该是一个，任何支持的二进制文件都将是单独的项目，安装程序将是一个单独的项目，等等。
每个项目都会生成一个主要可交付成果：一个 .EXE、一个 .DLL、一个 .HLP、该可交付成果被“发布”到单个共享的本地输出目录。
创建一个目录树，其中子项目是对等的（没有深度或层次结构，因为它没有帮助），并且不要让项目“到达”彼此的子树 - 每个项目应该完全独立，仅依赖于主要可交付成果其他子项目的，在共享输出目录中引用。
不要创建相互调用的构建脚本的层次结构，我这样做了，发现它不会增加价值，但会成倍地增加维护工作。 相反，创建一个调用独立构建脚本的持续集成脚本，但首先对临时目录进行干净的检出。
不要将任何可交付成果或依赖项提交到源代码管理中——不是您的构建输出，不是您使用的库等。针对与源代码控制分开部署的类似 Maven 的二进制存储库使用 Ivy，并向其发布您自己的可交付成果用于在您的组织内共享。
哦，不要使用 Maven——它太复杂了，混淆了构建过程，因此定制起来不划算。
我正在根据我的目标平台转向 SCons、BuildBot、Ant、Ivy、nAnt 等。
我一直在撰写关于这个主题的白皮书，我认为它可能会有读者。
编辑：请参阅我对 如何组织版本的详细回答控制存储库？
Having setup literally hundreds of projects over the years, and having specialized in software configuration management and release engineering, I would recommend that you first focus on how you want to build/release your project(s).
If you only use an IDE to build (compile and package) your project(s), then you might as well just follow the conventions typical for that IDE, plus any "best practices" you may find.
However, I would strongly recommend that you do not build only with an IDE, or even at all. Instead, create an automated build/release script using one or more of the many wonderful open-source tools available. Since you appear to be targeting Windows, I recommend starting with a look at Ant, Ivy, and the appropriate xUnit (jUnit for Java, nUnit for .NET, etc.) for testing.
Once you start down that path, you will find lots of advice regarding project structure, designing your build scripts, testing, etc. Rather than overwhelm you with detailed advice now, I will simply leave you with that suggestion--you will readily find answers to your question there, as well as find a whole lot more questions worth investigating.
Enjoy!
Based on comments, it seems that some detail is needed.
A particular recommendation that I would make is that you separate your codebase into individual subprojects that each produce a single deliverable. The main application (.EXE) should be one, any supporting binaries would each be separate projects, the installer would be a separate project, etc.
Each project produces a single primary deliverable: an .EXE, a .DLL, a .HLP, etc. That deliverable is "published" to a single, shared, local, output directory.
Make a directory tree where the subprojects are peers (no depth or hierarchy, because it does not help), and do NOT let projects "reach" into each other's subtree--each project should be completely independent, with dependencies ONLY on the primary deliverables of the other subprojects, referenced in the shared output directory.
Do NOT create a hierarchy of build scripts that invoke each other, I did and found that it does not add value but does exponentially increase the maintenance effort. Instead, make a continuous integration script that invokes your stand-alone build script, but first does a clean checkout into a temporary directory.
Do NOT commit any deliverables or dependencies into source control--not your build output, not the libraries that you use, etc. Use Ivy against a Maven-like binary repository that you deploy separate from source control, and publish your own deliverables to it for sharing within your organization.
Oh, and don't use Maven--it is too complicated, obfuscates the build process, and therefore is not cost-effective to customize.
I am moving towards SCons, BuildBot, Ant, Ivy, nAnt, etc. based on my target platform.
I have been composing a whitepaper on this topic, which I see may have an audience.
EDIT: Please see my detailed answer to How do you organize your version control repository?
为什么是5.x？ （在projectA下）
我认为在树中引入版本没有用 - 这就是 subversion 等的用途。
why the 5.x? (under projectA)
I don't think it is useful to introduce the versions in the tree - that is what subversion, etc is for.