我的小组中有3个开发人员，他们都在同一个项目上工作，这是一个.NET VB系统。 它们通常在不同的功能上工作，但通常会发生冲突，因为它们会更改相同的文件。 源文件在网络设备上共享，当然每个人都有自己的工作副本（WC）。 问题是，设置SVN存储库的最佳解决方案是什么？ ：
1）我在Trunk目录上导入主要源文件，然后在3个不同的WC上签出，每个WC用于本地计算机上的特定用户，然后处理来自该单个Repos的所有冲突/合并/提交/更新。分支。
2）我在Trunk目录上导入主要源文件，然后复制到单个“Branches”目录，然后从那里处理所有操作。设置好所有内容后，我处理主干和分支之间的合并
3）我在Trunk目录上导入主要源文件，然后复制到3个不同的“分支”目录，如：
svn copy trunk - ＆gt; branches / user1; svn copy trunk - ＆gt; branches / user2; svn copy trunk - ＆gt;分支机构/用户3
然后处理所有不同的合并，我认为这有点复杂 4）任何其他解决方案？
很多。
答案 0 :(得分：1)
我更喜欢选项＃3，因为它允许每个开发者保持个人历史记录。分支和合并越容易完成，因此您可能会发现这在短期内可行。此工作流程也很好地映射到feature branching，我认为这是最佳做法。
从长远来看，如果您计划扩展此团队，SVN不适合此工作流程。如果您想以这种方式工作，请考虑使用Git或Mercurial等DVCS，因为它们可以大大简化分支和合并。
答案 1 :(得分：0)
听起来你应该采用早期的分支模型。将主要来源导入trunk，然后将其分支并让您的团队为此工作。可能存在这样的情况：在正常开发期间，一个人的变化与另一个人的变化发生冲突，但这在任何版本控制系统中都是可以预期的。积极主动并将其作为学习经验。如果您对分支中的工作感到满意，请将其合并回trunk。
一些指示：
trunk为王。除非你真的知道你正在做什么，trunk应该总是处于“黄金”状态，这意味着不应该提交破坏构建的提交。答案 2 :(得分：0)
首先，您说“源文件在网络设备上共享”。你是什么意思？对于某些网站，他们拥有共享网络驱动器，并使用file://进行结帐和签到。如果你这样做，不要这样做。请改用svnserve或Apache HTTPD。 svnserve在Windows上很容易设置，并且有关如何将svnserve设置为Windows服务的方向很多，因此它会自动启动并重新启动。主要问题是网络上的端口3690是否被阻止。还有几个Windows软件包将安装已经集成的Apache httpd和Subversion。有些是完全开源的解决方案，但大多数是免费的。
偶尔的文件冲突应该不是问题。 Subversion能够以非常理智的方式处理冲突。假设开发人员 A 检出工作副本，开发人员 B 也是如此。开发人员 A 和 B 都会更改foo.vbs。开发人员 B 首先提交其副本。当Developer A 尝试提交更改时，Subversion将不允许开发人员 B 提交，直到开发人员 B 更新其工作副本以包含Developer A 的变化。一旦开发人员 A 执行此操作并测试其更改，他们就可以提交组合的更改集。这是你的第一个场景。
使用场景＃3，让每个开发人员在一个单独的分支上工作，与场景＃1完全相同：开发人员 A 和 B 都创建了一个分支从各自的分行收取行李和结账。他们可以在没有合并的情况下将他们的工作提交到他们自己的分支，但迟早，他们必须将他们的代码合并回主干。然后，他们将遇到相同的问题，第一个开发人员可以轻松地进行合并，但第二个开发人员必须处理任何合并冲突。
唯一的区别是你必须处理合并冲突。场景＃3允许开发人员忽略合并冲突直到游戏的最后阶段，这使得处理合并变得更加困难。场景＃1迫使开发人员在问题仍然很小时立即处理问题。我有几十个开发人员都在同一个分支上工作，没有任何问题。