具有不同svn存储库的不同项目中的代码管理

Question

首先，我想告诉你我有什么样的系统，我想要建立。

1- A Solution (has)
   a- Shared Class Library project (which is for lots of different solutions)
   b- Another Class Library project (which is only for this solution)
   c- Web Application project (which main part of this solution)
   d- Shared Web Service project (which also serves for different solutions)

2- B Solution (has)
   a- Shared Class Library project (which is for lots of different solutions)
   c- Windows Form Application project (which is main part of this solution)
   d- Web Service project (which also serves for different solutions)

和其他类似的项目......

我使用xp-dev.com作为我们的svn存储库服务器。 我为这些项目打开了不同的项目（ 共享类库，Web服务项目，Windows窗体应用程序项目，Web应用程序项目，另一个类库项目 ）。

我当然希望对所有这些项目进行版本控制。

我的第一个问题是，我是否应该将每个项目（一个解决方案）放到一个svn存储库中以便稍后获取其修订版号？

或者我应该将它们中的每一个放到不同的svn存储库中并保留（写下）用于发布/部署每个解决方案的正确版本号？

如果我为每个项目使用一个svn（共享类库，Web应用程序，共享Web服务......），如何在真实解决方案中将VS.2010上的正确svn地址和版本关联起来？

那么，您如何管理您的存储库和项目？

Answer 1

我相信对此的正确解决方案是标记。 我不相信将您的解决方案分隔到不同的存储库是个好主意。 建议在同一个存储库中保留所有甚至略有相关的项目，并使用标准的存储库布局，即：

/枝
/标签
/树干

使用上面描述的所有工作解决方案文件夹在/ trunk中。 Trunk可以包含您认为可管理的项目/解决方案，甚至可以按项目类型进一步组织。 我的一个主干文件夹是/ trunk / website，我将所有的网站解决方案保存在那里。

当您准备好发布版本时，您可以使用“分支/标记”覆盖/标记/“标记”您的主干或部分主干，这样您就有机会记录您的在标记的副本中发布说明。

有关SVN中的分支和标记的更多信息（假设Tortoise），请参阅TortiseSVN文档中的分支/标记 。

有关这些术语的更多信息， 请参阅 StackOverflow中的此问题 。

我希望这是有帮助的。 我不知道您的SVN主机可能面临的限制。 这些建议是基于我在托管我自己的VisualSVN Server存储库方面的经验。

我从SourceSafe来到SVN，花了一些时间才看到这个标准的价值，并开始使用这些实践。 它们对我来说非常宝贵。

Answer 2

您可以采用的另一种方法是使用Subversion externals属性来管理您的代码，可以在单独的存储库中，也可以在单个存储库中。 优点是，当您需要在解决方案中使用新版本的共享代码时，您可以简单地更新相关URL。

注意 ：我不记得关于Visual Studio解决方案和项目组织的杰克; 自从我完成任何Windows开发以来至少已有5年了。 话虽这么说，无论文件/目录布局是什么，这个讨论都适用。 我打算做一个，请根据你的实际情况进行调整。

让我们假设您有一个大型存储库，其中包含所有相关项目。 如果你认为这不一定是可扩展的，我建议看看Apache项目的SVN设置 ; 他们将所有项目都放在一个存储库中。 从ASF获取页面，让我们按如下方式开始存储库结构：

/SolutionA/trunk
/SolutionA/tags
/SolutionA/branches

/SolutionB/trunk
/SolutionB/tags
/SolutionB/branches

/SharedClassLib/trunk
/SharedClassLib/tags
/SharedClassLib/branches

/SharedWebService/trunk
/SharedWebService/tags
/SharedWebService/branches

到目前为止，这只是一个标准的SVN布局; 每个或多或少的独立实体都有自己的存储库区域。 现在，让我们假设您已经开始使用SharedClassLib，并且您的版本为2.0.0，而在SharedWebService上您使用的是版本1.2.5。 目录布局如下所示：

/SharedClassLib/tags/1.0.0
/SharedClassLib/tags/1.5.0
/SharedClassLib/tags/2.0.0

/SharedWebService/tags/1.0.0
/SharedWebService/tags/1.2.0
/SharedWebService/tags/1.2.5

其他标签只是为了说明您的开发一直在不断发展并且您已经有多个版本。

现在，回到SolutionA，您有一个LocalClassLibrary项目和一个LocalWebApp项目。 这些项目严格地是此解决方案的一部分，不在此解决方案之外共享。 在目录布局中进行攻击，您的主干可能看起来像：

/SolutionA/trunk/SolutionA/<some_solution_level_files>
/SolutionA/trunk/SolutionA/LocalClassLibrary/<some_project_level_files>
/SolutionA/trunk/SolutionA/LocalWebApp/<some_project_level_files>

所以，我们的问题是，我们如何将SharedClassLib和SharedWebService纳入我们的SolutionA？ 通过使用Subversion外部。 首先阅读外部网页，然后回到这里。

为了让您的生活更轻松，我建议您在解决方案目录中创建一个svn.externals文件，以便在从命令行执行此操作时设置svn：externals属性。 如果您正在使用其他工具，请记住，在这种情况下，您将需要添加多行。 该文件将如下所示：

SharedClassLib         http://your.svn.server/SharedClassLib/tags/2.0.0
SharedWebService       http://your.svn.server/SharedWebService/tags/1.2.5

编辑1 ：此时，您可以看到您引用的URL是完全限定的。 这意味着它们可以是单独的存储库，您不必使用我在此描述的布局。 此外，如果您处于开发的中间阶段，并且需要最新的，前沿的共享代码开发版本，请使用http://your.svn.server/SharedClassLib/trunk类的URL。 但是，在某些时候，在标记和发布解决方案之前，您将需要确定外部代码的黑貂版本。

编辑2 ：请注意，这是1.5之前的svn语法。 它在1.5中有所改变

做一个svn propset svn:externals -F svn.externals . 在您的解决方案目录中，然后svn commit && svn update 。 此时，svn将使用这些URL的内容填充您的工作副本。 您的工作副本看起来像：

./SolutionA/svn.externals
./SolutionA/<some_solution_level_files>
./SolutionA/LocalClassLibrary/<some_project_level_files>
./SolutionA/LocalWebApp/<some_project_level_files>
./SolutionA/SharedClassLibrary/<some_project_level_files>
./SolutionA/SharedWebApp/<some_project_level_files>

当您需要引入共享项目的新版本时，请相应地更新svn：externals属性。 请注意，这种方法有一些注意事项，并在SVN外部文档中有详细说明。 主要是，不打算能够在./SolutionA/SharedClassLibrary中进行更改，并期望在SolutionA中提交时可以神奇地获取更改。

现在您已准备好向全世界发布SolutionA。 只需在trunk目录中创建trunk的相应标记（svn copy）：

/SolutionA/tags/1.0.0

现在，您的SolutionA将在正确的标记/版本上拥有自己的代码，并且您正在为该版本使用正确版本的共享项目。

显然，同样的讨论适用于SolutionB。

我有一段时间没有和SVN合作过，所以如果我上面的任何一点有点不对，我很抱歉。

Answer 3

我的建议是将相同的生命周期放入相同的存储库项目中 。

我们来看看你的场景吧。 我们有：

1. 共享类库项目（适用于许多不同的解决方案）
2. 另一个类库项目（仅适用于此解决方案）
3. Web应用程序项目（该解决方案的主要部分）
4. 共享Web服务项目（也适用于不同的解决方案）

这将为2和3创建一个存储库，它们是同一解决方案的不同项目（因此具有相同的生命周期）：

/solution-A/trunk/ClassLib
/solution-A/trunk/WebApp
/solution-A/tags/1.0.0/ClassLib
/solution-A/tags/1.0.0/WebApp

假设他们有不同的生命周期，一个存储库为1，另一个为4。

/library-A/trunk/ShClassLib
/library-A/tags/1.0.0/ShClassLib
/library-B/trunk/ShWebService
/library-B/tags/1.0.0/ShWebService

现在，根据开发人员正在使用的主题，他可以检查主干，标签（只读）或分支。 例如，使用已发布的库处理解决方案的开发人员将检查解决方案的主干和库的正确标签。 需要下一版本库的同一个将检查库的主干（或分支）等。

当然，拥有一个能够为库和夜间构建提供二进制版本的构建/发布系统可能会更好。

Answer 4

关于Visual Studio支持真的没什么可说的，因为使用Subversion和Tortoise在Visual Studio中不起作用。 在处理项目和解决方案时，您可能需要仔细考虑项目和解决方案设置是否会影响其他用户。 例如，如果您的本地路径与存储库中的项目不同，则可能必须签出项目和解决方案文件并将其永久签出。

对于Web应用程序，如果文件中存在特定于计算机的设置，则可能需要仔细考虑web.config文件。 例如，如果您正在运行IIS 7并且下载了使用IIS 6创建的项目，则项目文件可能会更改为指向不同位置的系统模块和处理程序引用。 或者，您可能有一个连接字符串指向与原始web.config文件不同的服务器。 这里的解决方案也是最初下载文件，然后在本地检出文件并记住不要更新它。

我真诚的建议是把项目放到同一个库中; 它很容易找到和备份。 但是在创建新分支并在存储库中添加新文件时要记住的关键是：

首先在存储库中创建文件夹

只将文件夹签出到本地文件夹

在资源管理器中添加Tortoise文件

提交更改

边注：

如果您希望将Visual Studio集成用于源代码控制，则可以查看VisualSvn ，它直接从Visual Studio中提供与TortoiseSVN的集成。 Visual SVN适用于您现有的Subversion文件夹，因此它不使用Visual Studio版本控制提供程序（恕我直言）。 而是与TortoiseSVN API对话并直接从文件存储中获取数据。 我没有使用Visual SVN很长时间，但到目前为止它看起来不错，虽然我已经习惯使用资源管理器进行源代码控制，但它对于集成并没有多大帮助。

有一件事情肯定更容易创建新项目 - 您可以使用Add to Subversion，VSVN将负责创建分支并为您检出文件。

在IDE中查看文件的状态非常好，如果您经常向系统添加新文件，这也很好，因为VSVN知道Visual Studio文件关联并自动添加所有相关文件。