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

时间：2010-12-30 09:16:37

标签： visual-studio svn

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

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存储库中并保留（写下）用于发布/部署每个解决方案的正确版本号？ alt text

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

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

4 个答案:

答案 0 :(得分：6)

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

/分支
/标签
/中继线

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

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

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

有关这些术语的详细信息，请参阅StackOverflow中的see this question。

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

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

答案 1 :(得分：4)

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

  

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

让我们假设您有一个包含所有相关项目的大型存储库。如果您认为这不一定是可扩展的，我建议您查看Apache projects SVN setup;他们将所有项目都放在一个存储库中。从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外部。首先阅读externals网页，然后返回此处。

为了让您的生活更轻松，我建议您在解决方案目录中创建一个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 ：此时，您可以看到您引用的网址是完全限定的。这意味着它们可以是单独的存储库，您不必使用我在此描述的布局。此外，如果您处于开发的中间阶段，并且需要最新的，前沿的共享代码开发版本，请使用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。只需在标签目录中创建干线的相应标签（svn副本）：

/SolutionA/tags/1.0.0

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

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

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

答案 2 :(得分：1)

答案 3 :(得分：1)

关于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将负责创建分支并为您检出文件。

如果您经常在系统中添加新文件，因为VSVN知道Visual Studio文件关联并自动添加所有相关文件，那么在IDE中查看文件的状态肯定会很高兴。

相关问题
最新问题