组织解决方案，项目和SVN [英] Organizing solutions, projects and SVN
问题描述
我想在帮助在SVN中设置一个关于目录结构的项目。我已经阅读了关于这一点的几个答案，但因为我是新的，大多数是很难理解。
我建立一个单一的库，几个其他不同的项目取决于：
我需要能够轻松地导出MyLibrary（headers和.lib）供第三方使用
MyLibrary1
- 取决于外部库，应该能够管理这些库的不同版本！
MyLibrary2
- 取决于外部库fmod，glew， ...
项目1，2，4，5，6 ...
- 取决于MyLibrary1,2或两者
- 每个项目可能需要多个平台的版本（osx，windows ...）
我想知道一个很好的方法来组织这个，请记住，我是一个新的 - 更多的教育答案将是帮助。例如，如果你写的东西像/ src，做解释什么是应该进去！我可以猜到，但我不能肯定=）
///////////////////// ////////////////////////////////////////////////// /////////////////////////////////////
// Edit
我不能把这个变成一个注释，所以这里：
@JN，感谢广泛的回复，我想澄清一些东西，我希望我明白你的意思是正确的：
root
库foo
/ branches / /旧版本的foo
/ tags //发布foo
/ trunk //当前版本
/ build // makefiles需要的东西
/ tools //脚本启动测试ect
/ data //运行时需要的测试数据
/ output //二进制文件，.exe文件
/ dependencies // foo需要的库
/ lib name
include
lib
/ docs //文档
/ releases //生成的压缩文件
/ sample //显示如何使用foo的示例项目
/ source // * .h，* .cpp
程序栏
/ branches //旧版本的bar
/ tags //版本的bar
/ trunk //当前版本
/ build // makefiles需要的东西
/ tools //脚本启动测试ect
/ data //运行时需要的测试数据
/ output //二进制文件，.exe文件
/ dependencies //需要的库文件
/ lib name
include
lib
/ docs //文档
/ releases //生成的档案
/ sample //示例项目，显示如何使用bar
/ source // * .h，* .cpp
1）* .sln文件在哪里？ in / build？
2）我需要将foo / source复制到bar / dependencies / foo / include中吗？毕竟，bar取决于foo
3）.dll文件在哪里？如果foo依赖于dll文件，那么所有使用foo的程序都需要访问相同的dll文件。
有几个层次的问题：如何组织单个项目源码树，如何维护不同的项目在一起，如何维护这些项目的依赖，如何维护每个项目的不同变体和如何打包它们。
请记住无论你做什么，你的项目将最终增长到足以使其无适应。在项目的生命周期中多次更改结构是正常的。你会得到的感觉，这将是不正确的，当这将发生：通常是当设置打扰你比它有帮助。
1 - 维护每个项目的不同变体
没有每个项目的变体，不会通过维护parralel版本或分支来解决几个变体。对于可用于所有变体的每个项目/库，都有单个源代码树。不要管理不同的操作系统，管理不同的功能。也就是说，在诸如支持posix套接字或支持UI之类的东西上有变体。这意味着如果一个新的操作系统来了，你只需要选择它支持的功能集，而不是开始一个新的版本。
当需要特定的代码时，创建一个接口（C ++中的抽象类），并实现相对于它的行为。这将隔离有问题的代码，并将有助于在将来添加新的变体。
2 - 维护每个项目的依赖关系
有一个特定的dependencies文件夹，其中每个子文件夹包含一个依赖关系所需的所有内容（即包含和子依赖关系）。在代码库不太大的时候，你并不在意自动确保所有的依赖关系都是相互兼容的，以后再保存它们。
不要尝试从svn层次结构中较高的根位置合并依赖项。正式提交每个新版本给需要它的团队，由他们更新自己的SVN部分。
不要尝试使用几个版本的同时依赖。这将结束得很糟糕。
如果您确实需要（但尽量避免使用它，
3 - 维护不同的项目
我建议保持每个项目库独立（使用SVN他们仍然可以是相同的repo，在分离的文件夹中）。分支和标签应该针对一个项目，而不是所有项目。尝试限制到最大分支数，他们不解决问题（即使用git）。如果你必须并行维护不同的chronoligical版本（不是变体）并尽可能多地回击，在你实际做之前，每个人都将从使用较新的代码中受益。 p>
这将允许实施安全限制（不确定如果可行，使用香草SVN，但有一些免费提供的服务器支持它）。
我建议每当有人向某个可能感兴趣的人提交项目时发送电子邮件通知。
4 - 项目源树组织
每个项目都应该具有以下SVN结构：
- trunk（当前版本）
- 分支（旧版本，仍在使用）
- 当需要补丁时）
当项目变大时，在子文件夹（例如分支/ V1.0 / V1.1和分支/ V2.0 / V2.1）中组织分支和标签。
有一个包含以下子文件夹的根文件夹：（其中一些可能由VC自己创建）
- 构建系统（您的makefiles或其他需要的东西）
- 工具（如果有的话，例如XSLT工具或SOAP编译器，测试）
- 数据（运行时需要的测试数据）
- 输出（构建系统放置二进制文件的位置）
- 临时文件输出（由编译创建的临时文件，可选）
- 依赖关系
- 文档（如果有） / li>
- 发布（生成的档案见后文）
- 示例（演示如何使用项目/库的小项目）
- 源代码（我不喜欢拆分头文件和.cpp，但这是我的方式）
- 避免过多的子文件夹，很难搜索树，列表更容易
- 正确定义每个文件夹的构建顺序（对于VC而言更少）
- 我使我的命名空间与我的文件夹名称匹配（旧的Java习惯，但工程）
- 清楚定义您需要导出的公共部分
- 如果项目足够大几个二进制文件/ dll都应该有自己的文件夹
您生成的二进制文件，只有版本。
5 - 包装项目
首先，确保包含SVN修订版本和日期的文本文件，使用自动道具可以自动执行此操作。
您应该有一个脚本来生成版本（如果时间允许）。它将检查一切是否已提交，生成新版本号....创建一个zip / tar.gz归档文件，您必须提交/归档，其名称包含SVN修订版本，分支和当前日期（格式应标准化项目）。存档应该具有运行应用程序/在文件结构中使用库所需的一切。创建一个标签，以便您可以从中进行紧急修复错误。
I would like some help in setting up a project in SVN with regards to directory structure. I have read several answers regarding this on SO, but as I am new to this, most of them are difficult to understand.
I am building a single library, on which several other distinct project depends on:
I need the ability to export MyLibrary (headers and .lib only) easily for use by third parties
MyLibrary1
- Depends on external libraries, should be able to manage different versions of these libraries!
MyLibrary2
- Depends on External Libraries fmod, glew, ...
Project 1, 2, 4, 5, 6 ...
- Depends on MyLibrary1, 2, or both
- Each project could need versions for multiple platforms (osx, windows ...)
I would like to know of a good way to organize this, do keep in mind that I am rather new to this - a more pedantic answer would be helpful. For example if you write something like /src, do explain what is supposed to go into it! I would be able to guess, but I wont be sure =)
////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Edit
I cant put this into a comment, so here goes: @J.N, thanks for the extensive reply, I would like to clarify some stuff, I hope I understood what you meant properly:
root
library foo
/branches // old versions of foo
/tags // releases of foo
/trunk // current version
/build // stuff required by makefiles
/tools // scripts to launch tests ect
/data // test data needed when running
/output // binaries, .exe files
/dependencies // libraries that foo needs
/lib name
include
lib
/docs // documentation
/releases // generated archives
/sample // sample project that shows how to use foo
/source // *.h, *.cpp
program bar
/branches // old versions of bar
/tags // releases of bar
/trunk // current version
/build // stuff required by makefiles
/tools // scripts to launch tests ect
/data // test data needed when running
/output // binaries, .exe files
/dependencies // libraries that bar needs
/lib name
include
lib
/docs // documentation
/releases // generated archives
/sample // sample project that shows how to use bar
/source // *.h, *.cpp
1) Where do the *.sln files go? In /build?
2) do I need to copy foo/source into bar/dependencies/foo/include? After all, bar depends on foo
3) Where do *.dll files go? If foo has dependencies on dll files, then all programs using foo need access to the same dll files. Should this go into root/dlls?
There are several levels to your questions: how to organize a single project source tree, how to maintain the different projects together, how to maintain the dependencies of those project, how to maintain different variants of each projects and how to package them.
Please keep in mind that whatever you do, your project will eventually grow large enough to make it unadapted. It's normal to change the structure several times in the lifetime of a project. You'll get the feeling that it isn't right anymore when that will happen: it's usually when the setup is bothering you more than it helps.
1 - Maintaining the different variants of each project
Don't have variants for each project, you won't solve several variants by maintaining parralel versions or branches. Have a single source tree for every project/library that can be used for all variants. Don't manage different "OSes", manage different features. That is, have variants on things like "support posix sockets" or "support UI". That means that if a new OS come along, then you just need to choose the set of features it supports rather than starting a new version.
When specific code is needed, create an interface (abstract class in C++), and implement the behaviour with respect to it. That will isolate the problematic code and will help adding new variants in the future. Use a macro to choose the proper one at compile time.
2 - Maintaining the dependencies of each project
Have a specific "dependencies" folder in which each subfolder contains everything needed for one dependency (that is includes and sub dependencies). At the beggining when the codebase is not too large, you don't care too much about ensuring automatically that all the dependencies are compatible with each other, save it for later.
Don't try to merge the dependencies from their root location higher in the svn hierarchy. Formally deliver each new version to the teams needing it, up to them to update their own part of the SVN with it.
Don't try to use several versions of the same dependency at once. That will end badly. If you really need to (but try avoiding it as much as you can), branch your project for each version.
3 - Maintain the different projects
I'd advise to maintain each projects repository independently (with SVN they still could be the same repo, but in separated folders). Branches and tags should be specific to one project, not all of them. Try to limit to a maximum the number of branches, they don't solve problems (even with git). Use branches when you have to maintain different chronoligical versions in parallel (not variants) and fight back as much as you can before you actually do it, everybody will benefit from the use of the newer code.
That will allow to impose security restrictions (not sure if feasible with vanilla SVN, but there are some freely available servers that support it).
I'd recommend sending emails notifications whenever someone commits on a project to everybody potentially interested.
4 - Project source tree organization
Each project should have the following SVN structures:
- trunk (current version)
- branches (older versions, still in use)
- tags (releases, used to create branches without thinking too much when patches are required) When the project gets bigger, organize branches and tags in sub folders (for instance branches/V1.0/V1.1 and branches/V2.0/V2.1).
Have a root folder with the following subfolders: (some of this may be created by VC itself)
- Build system (stuff required by your makefiles or others)
- Tools (if any, like an XSLT tool or SOAP compiler, scripts to launch the tests)
- Data (test data you need while running)
- Output (where the build system put the binaries)
- Temp Output (temporary files created by the compilation, optional)
- Dependencies
- Docs (if any ;) or generated docs)
- Releases (the generated archives see later)
- Sample (a small project that demonstrate how to use the project / library)
- Source ( I don't like to split headers and .cpp, but that's my way )
- Avoid too many levels of subfolders, it's hard to search trees, lists are easier
- Define properly the build order of each folder (less necessary for VC but still)
- I make my namespaces match my folders names (old Java habits, but works)
- Clearly define the "public" part that you need to export
- If the project is large enough to hold several binaries / dlls each should have its own folder
Don't commit any binaries you generate, only the releases. Binaries like to conflict with each other and cause pain to the other people in the team.
5 - Packaging the projects
First, make sure to include a text file with the SVN revision and the date, there's an automated way to do that with auto props.
You should have a script to generate releases (if time allows). It will check that everything is commited, generate a new version number .... Create a zip/tar.gz archive you must commit/archive, whose name contains the SVN revision, branch and the current date (the format should be normalized accross projects). The archive should have everything that is needed to run the app / use the library in a file structure. Create a tag so that you can start from it for emergency bug fixing.
这篇关于组织解决方案，项目和SVN的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
