具有不同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存储库中并保留(写下)用于发布/部署每个解决方案的正确版本号？
如果我为每个项目使用一个svn(共享类库,Web应用程序,共享Web服务......),我怎样才能在真实解决方案中将VS.2010上正确的svn地址和版本关联起来？
那么,您如何管理您的存储库和项目？
我相信对此的正确解决方案是标记.我不相信将您的解决方案分隔到不同的存储库是个好主意.建议在同一个存储库中保留所有甚至略有相关的项目,并使用标准的存储库布局,即:
/ branches
/ tags
/ trunk
使用上面描述的所有工作解决方案文件夹在/ trunk中.Trunk可以包含您认为可管理的项目/解决方案,甚至可以按项目类型进一步组织.我的一个主干文件夹是/ trunk/website,我将所有的网站解决方案保存在那里.
当您准备好发布版本时,您可以使用"分支/标记"覆盖/标记/"标记"您的主干或部分主干,这样您就有机会记录您的在标记的副本中发布说明.
有关SVN中的分支和标记的更多信息(假设Tortoise),请参阅TortiseSVN文档中的分支/标记.
有关这些术语的更多信息,请参阅 StackOverflow中的此问题.
我希望这是有帮助的.我不知道您的SVN主机可能面临的限制.这些建议是基于我在托管我自己的VisualSVN Server存储库方面的经验.
我从SourceSafe来到SVN,花了一些时间才看到这个标准的价值,并开始使用这些实践.它们对我来说非常宝贵.
您可以采取的另一种方法是使用 Subversion externals属性来管理您的代码，无论是在单独的存储库中还是在单个存储库中。优点是，当您的解决方案中需要新版本的共享代码时，您可以简单地更新相关 URL。
注意：我不记得 Jack 关于 Visual Studio 解决方案和项目组织的事情了；我已经至少有 5 年没有做过任何 Windows 开发了。话虽这么说，无论文件/目录布局是什么，这个讨论都适用。我准备了一份，请根据您的实际情况进行调整。
假设您有一个大型存储库，其中包含所有相关项目。如果您认为这不一定是可扩展的，我建议您查看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. 然而，在某些时候，您可能希望在标记和发布解决方案之前确定外部代码的稳定版本。
编辑 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 的相应标签（svn 副本）创建到 tags 目录即可：
/SolutionA/tags/1.0.0
现在，您的 SolutionA 将在正确的标签/版本上拥有自己的代码，并且您正在使用该版本的共享项目的正确版本。
显然，同样的讨论也适用于SolutionB。
我已经有一段时间没有使用 SVN 了，所以如果我上面的内容有一点错误，我深表歉意。
| 归档时间： |
|
| 查看次数： |
1785 次 |
| 最近记录： |