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

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

---

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

我认为正确的解决方案是标记。我认为在不同的存储库中分离解决方案不是一个好主意。建议将所有稍微相关的项目保留在同一个存储库中，并使用标准存储库布局，即：

/分支机构
/标签
/树干

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

当您准备好发布版本时，您可以使用“分支/标记”切换到/tags/使用该版本或构建版本“标记”您的主干或主干的一部分，这也为您提供了在标记副本中记录发行说明的机会

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

有关这些条款的更多信息，请访问StackOverflow

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

---

我是从SourceSafe来到SVN的，花了一些时间来了解这个标准的价值，并开始使用这些实践。它们现在对我来说是无价的。

我的建议是将它们放在具有相同生命周期的相同存储库项目中

让我们看一个场景。我们有：

共享类库项目（适用于许多不同的解决方案）

另一个类库项目（仅适用于此解决方案）

Web应用程序项目（此解决方案的哪个主要部分）

共享Web服务项目（也可用于不同的解决方案）

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

一个存储库用于1，另一个存储库用于4，假设它们具有不同的生命周期

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

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

---

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

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

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

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

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

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

在资源管理器中添加带乌龟的文件

提交更改

旁注：

如果您希望将VisualStudio集成用于源代码管理，您可以直接从VisualStudio中查看哪个提供了与OrtoiseSVN的集成。Visual SVN与您现有的Subversion文件夹配合使用，因此它不使用Visual Studio版本控制提供程序（IMHO是一件好事）。相反，它与tortoisesvnapi对话，并直接从文件存储中获取数据。我已经很久没有使用visualsvn了，但是到目前为止它看起来很不错，尽管我已经习惯于使用Explorer进行源代码管理，但是它对集成没有太大帮助

有一件事绝对更容易，那就是创建新项目——您可以使用addtosubversion，VSVN将负责创建分支并为您检出文件

在IDE中看到文件的状态确实很好，而且它也是ni

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

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

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

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

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

/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/trunk/SolutionA/<some_solution_level_files>
/SolutionA/trunk/SolutionA/LocalClassLibrary/<some_project_level_files>
/SolutionA/trunk/SolutionA/LocalWebApp/<some_project_level_files>

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

./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>

/SolutionA/tags/1.0.0