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