首先我想告诉你我有什么样的系统，我想建立在什么样的系统上。
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 存储库并保留(记下)用于发布/部署每个解决方案的正确版本号？
如果我为每个项目(共享类库、Web 应用程序、共享 Web 服务...)使用一个 svn，我如何在真正的解决方案中关联正确的 svn 地址和 VS.2010 版本？
那么，您如何管理您的存储库和项目？
最佳答案
您可以采取的另一种方法是使用 Subversion externals 属性来管理您的代码，无论是在单独的存储库中还是在单个存储库中。优点是当您需要解决方案中共享代码的新版本时，您可以简单地更新有问题的 URL。
假设您有一个包含所有相关项目的大型存储库。如果您认为这不一定具有可扩展性，我建议您查看 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 :此时，您可以看到您所引用的 URL 是完全限定的。这意味着它们可以是单独的存储库，您不必使用我在此处描述的布局。此外，如果您处于开发的中间阶段，并且需要共享代码的最新、最前沿的开发版本，请使用类似
http://your.svn.server/SharedClassLib/trunk 的 URL。但是，在某些时候，您会想要在标记和发布解决方案之前确定外部代码的 sable 版本。编辑 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 将拥有自己的正确标记/版本的代码，并且您正在为该版本使用正确版本的共享项目。
显然，同样的讨论适用于解决方案 B。
我有一段时间没有与 SVN 一起工作了，所以如果我上面的任何一个有点错误，我很抱歉。
关于visual-studio - 不同项目中不同svn仓库的代码管理，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4561378/