使用 SVN 进行项目代码管理答案

【问题标题】：Project code managment using SVN使用 SVN 进行项目代码管理
【发布时间】：2009-12-01 09:31:41
【问题描述】：

我已经开始做一个项目。我想使用颠覆来存储这个项目。我已经安装了 VisualSVN 服务器和 TortoiseSVN。

这个项目由几个小项目组成。有些我每次都需要，有些不需要。问题是：

我应该将整个项目存储在一个 subversion 项目目录中吗？
解决方案文件 (*.sln) 怎么样？是否也应该存储在 SVN 中？
在项目上是某种框架（稍后将在其他项目中使用）。但是每次我在处理基础项目时都需要它。有什么方便的方法可以一次从不同的 SVN 目录签出/导出我的基础和框架项目？
如果我只需要在项目的一部分上工作，我应该怎么做？

【问题讨论】：

或许您也应该考虑试用 VisualSVN 客户端。

标签： .net svn tortoisesvn

【解决方案1】：

是的，简而言之 - 但您以后可以改变主意

一个颠覆项目的典型目录结构是：
```
project/branches
project/trunk
project/tags
```
您最初将所有代码放在主干中，然后在必要时创建标签和分支。

您最初可能需要考虑将所有内容放在一个 svn 项目文件夹结构中，因为它会更简单（您不必弄乱解决方案文件）。

如果您稍后选择将项目的部分拆分为单独的 svn 项目，您可以执行“svn 重命名”并为它们创建标准分支、主干和标签文件夹。您只需要修改解决方案文件中的引用或使用 svn:externals 方法。
绝对 - 您应该将所有不是由构建生成的内容存储在存储库中。在生成的文件夹（例如 obj 和 bin 目录）上创建 svn:ignore 属性，这样当您忘记添加重要文件时，“svn status”将为您提供有用的反馈。
有一种机制 svn:externals 使您能够创建到 subversion 存储库（或外部 subversion 存储库）中另一个位置的链接 - 这可能有助于您能够从单个文件夹中签出。您可能需要考虑对框架的特定标签进行 svn:external 引用，以便其他人对框架的更改不会破坏您的项目。

svn:externals 可能会使事情变得相当混乱，但是请谨慎使用。
您可以在 subversion 中的文件夹层次结构中的任何级别签出

【讨论】：

【解决方案2】：

通常一个 Subversion 存储库具有三个文件夹 trunk、branches 和 tags。您将把您的项目放在主干中。如果它们不直接相关，我会为每个项目创建一个存储库。

是的，我保留了 .sln 文件，但忽略了 .suo 和 cproj.user 文件。我也忽略了 bin 和 obj 文件夹。

如果您将“框架”项目保存在一个存储库中，您只需签出主干文件夹即可。如果您将其保存在另一个存储库中，您可以查看 externals 的概念

您通常会检查整个主干，即使您需要处理项目的特殊小部分。

SVN Book 可以帮助您了解更多信息。

【讨论】：

【解决方案3】：

将所有内容存储在一个目录中。目录的基础应该是解决方案文件。这也应该存储在 SVN 中（使得在新机器上从 SVN 签出解决方案变得更加容易）。

对于框架项目 - 尝试将其包含在解决方案中，然后在解决方案的基础项目中引用它。

如果您只需要处理项目的一部分，您可以打开整个解决方案并只处理您需要的部分，或者只签出该项目。

【讨论】：

【解决方案4】：

我已经设置了我们的内部 SVN 存储库，如下所示：

SVN-Root
    - trunk
        - Projects (for each project one folder,
                    Solutions are in separate folder)
    - tag
        - Projects
    - branch
        - Projects

不过，我读过类似这样的不同设置：

SVN-Root
    - Solution1
        - trunk
        - tag
        - branch
    - Solution2
        - trunk
        - tag
        - branch

【讨论】：

【解决方案5】：

由于您正在考虑使用多个 SVN 存储库，因此您应该考虑以下事项：在 SVN 存储库中提交是原子的。提交适用于多个存储库的更改不是。

即使您是唯一使用您的 SVN 存储库的人，经验法则是该系统旨在允许（理论上）任何人随时更新，并且不会冒着获取因错误而无法编译的源代码的风险时机。

总之，如果可能需要同时对文件 A 和 B 应用更改以保持项目可编译，那么 A 和 B 应该在同一个存储库中。

【讨论】：

【解决方案6】：

您可以根据您的目录结构存储项目。经验法则是一个 svn 目录一个 csproject
是的，您应该将sln 存储在SVN 中。您可以将此 sln 放在您的项目目录之一中（通常在您的 GUI csproject 文件夹中）
为此你需要使用SVN命令行来做；您可以为此编写一个批处理脚本。
您只需签出相关项目并着手处理即可。

【讨论】：

我能以任何方式处理来自 AnkhSVN 的#3 吗？

【解决方案7】：

1.) 你喜欢它。这完全取决于你。你想处理几个颠覆文件夹还是只处理一个？

2.) 是的，当然。只保留用户特定的文件（如 .user）。

3.) 不。好吧，也许吧。如果您使用 AnkhSVN 作为 Visual Studio 项目，那么您可以更新解决方案，所有项目文件夹都将随之更新。

4.) 仅使用该项目 ;-)

【讨论】：

【解决方案8】：

Subversion 存储库的设置是一个存在许多不同意见的主题。下面的答案是基于我个人的经验和喜好：

我建议将一个项目的多个模块存储在一个存储库中。这简化了整个项目的检查。当您将子项目放在主项目中自己的子目录中时，也可以单独签出各个子项目。
我不确定 *.sln 文件是什么，但如果构建项目需要它，它应该在您的存储库中。如果它已生成（或可以轻松生成）并且依赖于系统，则它不应成为您的存储库的一部分。
可以使用 svn 的 externals feature 包含其他存储库的一部分。
请参阅我在第 1 点的回答。

【讨论】：

【解决方案9】：

可能取决于您希望如何组织事物、各个部分的大小以及适合您的方式。尝试一下。

您可能想要研究的一件事是外部：(http://svnbook.red-bean.com/en/1.0/ch07s03.html)。这允许您从其他存储库中提取文件和文件夹。

【讨论】：

【解决方案10】：

对于我 - 经验法则是 1 SVN REPO = 1 SOLUTION

我也会签入 .sln 文件，并与所有参与该项目的人强制执行相同的目录结构

【讨论】：

我不同意。您可以将所有解决方案存储在一个存储库中。如果您有多个不共享源代码的团队，那么多个存储库可能是个好主意。