不久前，我们使用 Microsoft VSS 作为我们的版本控制工具，并用于在每个版本结束后创建我们的代码分支并将其部署到我们的客户。
现在我们已经转移到 SVN 并且最近有很多关于标签/分支的讨论，我们应该在开发特定版本之后标记/分支我们的代码吗？
SVN 实际上为此目的推荐了“标签”，但也建议不要进一步对其进行任何更改，那么我们将在哪里修复此版本中出现的令人发指的错误？
正在做的另一件事是创建标签和分支，将标签部署到客户端，如果出现任何错误，将对分支进行修复，然后再次标记:-(
其他人做什么？
在 Subversion 中，它们是相同的 - 它们以相同的方式实现并且结果相同（除了您的 repo 层次结构）。它们只是对存储库特定版本的引用。没有制作真正的副本。当你开始在一个分支上工作时（真正意义上的），那么你就是在一个新的地方使用该资源的一个新副本。
如果/需要时，您总是可以从标签中创建分支，因此没有理由创建分支和标签。
如果它可以帮助您保持一致，那么请继续执行它，但实际上在您开始签入/对分支进行修订之前它不会做任何事情。
（标签/分支都是用 cp 命令制作的）
是的，您通常会创建一个与主干平行的维护分支，并从中标记错误修复版本。
在代码行的特定版本（例如主干）上创建一个标签，并且总是从您的标签中发布。svn 中的标签虽然不是由 svn 本身强制执行的，但它是快照和参考点。利用这个隐含的概念，只发布从您和其他人知道对应于特定版本的标签创建的构建。
使用分支将维护补丁提交到特定版本（例如，如果您需要修补您的版本，则从您的标签创建一个分支）并通过在您发布时标记您的分支来为您的补丁遵循相同的做法。
发布分支上的标签。
由于源代码控制概念在这里仍然很新，尤其是 SVN，所以我们只在主干上工作。在我们有不应该上线的提交之前工作得很好，而当时部署的人并没有意识到这一点。
一旦每个人都对这里的 SVN 感到满意，并且我至少可以找到另一个熟悉合并的人，我将设置一个“实时”分支，所有已批准的生产提交都可以合并到该分支中。
标签很好，因为您可以为开发周期命名，“beta”、“alpha”、“release Candidate 1”等。但最重要的是，您需要一个可以依赖于生产使用的良好分支。标签只是让确定里程碑变得更容易。