SVN分支问题

创建分支时，选择以下选项的含义是什么

从以下位置在存储库中创建副本：

• 存储库中的HEAD修订
• 存储库中的特定修订
• 工作副本

简而言之：

• 从HEAD版本创建是从“now”开始创建分支，其中“now”是提交到存储库的最新版本
• “从特定修订创建”是指从过去的某个点（由其修订号标识）开始创建分支
• 从工作副本创建类似于从将来的某个点创建分支（您的工作副本，尚未提交）

根据创建分支的目的，您通常会选择前两个选项之一。第三种选择可能不太常用

---

如果你想为某个特定的目的进行探索性开发，或者你想开始为某个特定的客户或其他东西创建一个不同的版本，你可以从负责人那里分支。如果您需要对以前发布的软件版本进行修补，您可以从过去开始进行分支。

存储库中的HEAD revision SVN采用的版本号最高，因此是最后上载的版本

存储库的特定修订版 您可以选择要获取的修订

工作副本

---

该修订与您的本地工作区中的当前版本相同（未提交）。

HEAD将使分支成为存储库最新提交版本的副本

特定修订将导致分支在存储库的特定时间点成为副本

工作副本根据工作副本的最新版本创建分支，然后将所有“正在进行”的更改也提交到此分支

编辑： 选择工作副本的示例

您使用最新版本的主干更新工作副本，以开始进行一些小的更改

几小时后，你意识到这份工作比你预期的要大，你应该创建一个分支机构

此时从工作副本创建分支，然后有效地创建分支，就像您在一开始就创建了分支一样。

svn中的“创建分支”实际上只是复制存储库的某个子集。事实上，SVN的书上有一章

如果您的目录结构如下所示

• 计划
  • 树干
  • 分支机构
  • 标签

您的主干URL是：

http://example.com/repos/project/trunk

，您将：

从HEAD创建一个名为

beta

的新分支，如下所示：

svn copy http://example.com/repos/project/trunk http://example.com/repos/project/branches/beta

这将立即在存储库中创建新分支，而不会对本地副本做任何操作

从旧版本n中创建一个名为

古代

的新分支，如下所示：

这与1完全相同，但使用了特定的修订版

假设当前目录为

trunk

，则从本地副本创建一个名为

alpha

的分支：

cd ../
svn cp trunk branches/alpha

这将生成您请求的副本，但不会在本地生成。根据SVN的书，这是不鼓励的，因为它比在存储库服务器上进行复制（复制操作基本上是免费的）需要更长的时间

当您键入

svn help copy

时，还列出了以下警告：

警告：为了与以前版本的Subversion兼容， 使用两个工作复制路径（WC->WC）执行的复制不会 联系存储库。因此，默认情况下，他们可能无法 从副本源传播合并跟踪信息的步骤 去目的地

---

根据我的经验，通常使用1的方式2用于一些罕见的情况，涉及早期分支的复杂补丁，3从来没有用过（根据文档，速度慢，可能有危险）。因此，请坚持使用1，除非您有令人信服的理由使用另外两种方法中的一种。

谢谢您的详细描述，Greg；）在什么情况下，您会使用工作副本？既然最好是获取最新的代码，那么您可以使用此选项在您的工作区中共享一些未经充分测试的内容（例如，让同事再次查看或继续处理），这样就不应该将其上载到真正的svn分支。为了获得成功测试的最新代码，我将把它上传到存储库中，并从head修订版创建分支，这样您就可以100%地完成所有更改。谢谢罗宾。我的想法对吗？当你做了更改并将其提交到你创建的分支时，要将这些更改添加到主干中，你需要删除这些文件，然后从主干中签入这些文件，然后使用类似beyond compare的方法将这些文件添加到你刚刚签入的主干文件中？不，一点也不。您可以将更改合并回主干中。通常，您会将对主干所做的任何更改合并回分支中，以使其保持最新。然后将分支重新整合回主干。整个分支/合并概念是一个完全不同的问题，无法在评论中完全回答。我在写作中称选项3“可能有危险”，但在这种情况下，我认为这是好的。只要不存在任何svn:mergeinfo属性，您在进行本地复制时可能会遗漏这些属性，您可能就没事了。因为这是一个将全新作品复制到新分支的示例，所以我不认为文档中的警告适用于此。

cd ../
svn cp trunk branches/alpha