SVN 中的发布管理答案

【问题标题】：Release management in SVNSVN 中的发布管理
【发布时间】：2010-10-08 20:01:48
【问题描述】：

当我查看 SVN 日志时，我真的希望我能看到告诉我发布何时完成的标记。我在 PVCS 和 Perforce 等其他版本控制系统中看到了这一点。

这可以在 SVN 中完成吗？我做了一些研究，到目前为止，似乎不支持这种事情。

编辑

我们不希望每次发布都将源代码复制到不同的文件夹中。这会导致开发人员机器上出现大量不必要的文件重复，并且只为我们提供了每个版本的修订号的记录。我可以使用文本文档来做到这一点！

编辑2

我的目标是有一个单一的视图来显示我的版本的年表，在这之间我可以看到每个版本之间发生的所有代码更改。这样可以更轻松地编译发行说明。

【问题讨论】：

FWIW，副本很便宜——只复制引用，而不是文件——而且它们可以完全在服务器上完成，永远不会弄乱你的本地工作空间。
除非我误解了您的反对意见，否则副本发生在 SVN 存储库上，而不是在开发人员的机器上。阅读我链接的文章。
是的。 svn copy 不会复制每个文件。它是在恒定时间内完成的，通常需要大约 1 秒，无论项目有多大。试试吧。 :)
...并且开发人员机器不应该签出“标签”目录。 ;)
所以我不明白的是，您如何在仅签出“主干”文件夹的机器上查看每个版本的修订号。

标签： svn release-management

【解决方案1】：

并非如此。在 SVN 中进行发布的公认方法是有一个“标签”目录，其中为每个特定版本复制您的发布源。例如/tags/release-0.11 ... 没有任何东西可以防止您意外地弄乱tags 目录，开箱即用，但是有些人喜欢设置预提交挂钩以防止意外提交以释放标签。

这是一个decent article，描述了 SVN 中的发布过程。

【讨论】：

而且制作标签很便宜，因为 SVN 不会复制任何文件内容，除非它们被更改。
Adam 的链接文章是我发现的理论和实际用例细节的最佳组合。
此链接有效，devroom.io/2006/11/21/svn-how-to-release-software-properly
请注意，“发布管理”不仅仅是发布带有发布说明或更改日志的实际软件。主题包括集成方面、数据隐私、质量、生产环境等。

【解决方案2】：

我想提供一种不同的方法来帮助解决您所说的问题：创建版本说明并查看版本之间的代码差异。

我们使用 Tortoise SVN 附带的名为 SubWCRev 的实用程序。我们有一个构建后事件，它获取 SVN 修订号并将其粘贴到一个文件中 - 对于网站，我们将其放在一个名为 version.html 的文件中。然后在任何时间点，您都可以将您的版本（无论是当前在 QA、Prod 还是任何其他环境中的版本）与 SVN 中的确切修订号联系起来。不再需要标记，不再想知道发布中包含什么，不再需要开发人员来更新版本文件。

为了确定发布中包含的内容，您可以将 SVN 日志从修订 X 拉到修订 Y 并将 cmets 复制到文档中并进行编辑以制作漂亮的发布说明文档。代码审查或版本差异也是如此。只需使用与您的 version.html、properties.cs、readme.txt 等相关的修订号。

我还建议使用某种工件存储库来保存您的构建。如果您切换到使用 SVN 修订号作为您的版本号，您始终可以返回到 SVN 中的确切修订，这意味着您不需要为 SVN 中的每个版本提供源代码的标签或副本。

【讨论】：

【解决方案3】：

如果您遵循存储库根目录中“标签/分支/主干”的常规 svn 约定，开发人员通常不想检查整个存储库，只需要从主干向下检查。

【讨论】：

【解决方案4】：

我遇到了同样的问题，我尝试为我的公司修复它的方法是在主干中有一个“发布”文件夹，这个文件夹只包含实际的可执行文件或需要成为部署的一部分。

我在“发布”文件夹中为每个版本创建一个以“1.0.0.0”开头的新文件夹，并使用相同的发布文件夹名称标记代码，即案例中的 1.0.0.0。

我不确定这是否是正确的方法，但它解决了我的问题，以找出我已部署的可执行文件。

【讨论】：

【解决方案5】：

Richard，标签非常接近，但我想知道你需要的可能不是专门的发布分支。

为此，尽早从主干创建一个分支，称为“发布”。然后像往常一样在主干上工作，当你准备好发布时，将主干中的更改合并到“发布”中。这是您应该修改版本的唯一方法。

如果需要，您可以从发布中标记，而不是 100% 必要。

但这会给您一个分支，其中包含主干修订的子集。通过以下方式了解您的发布日期：

svn log --stop-on-copy svn://server/project/branches/release

这将为您提供发布日期列表（包括修订）。要查看每个版本中的内容，请执行以下操作：

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

另请注意，通过这种方式，您不仅限于严格按顺序发布主干中的所有内容 - 您可以挑选修订版，如果您还不想发布修订版，则将其排除在外，但仍包括后续修订。

【讨论】：

感谢 Jim T - 我想这可能正是我所需要的！
清晰简洁，节省时间！
这也是我们使用的解决方案。我们的主要绊脚石是我们致力于 /trunk 的工作，它还没有发布。这可能会导致繁琐的冲突解决。

【解决方案6】：

+1 用于使用提交消息。

对于一个项目，我创建了一个名为 build 的 SVN 用户。构建机器将此登录名用于 SVN。每当构建机器/进程进行构建时，它也会更新一个文件，并且 SVN 提交消息是构建的版本/其他标识符。

然后我们还为该构建创建了一个标签。通过这种方式，我们可以在主干中看到构建何时/何处穿插其他更改。

所以我的建议（最简单的方法）是创建另一个名为 build 的文件（或您想要的任何其他文件）并附加到该文件或只是在您的构建脚本/过程中对其进行修改，然后将其重新签入/提交以发布版本的名称作为提交消息。简单的。然后它将显示在您的历史查询中。

【讨论】：

【解决方案7】：

虽然 Subversion 本身不提供版本管理，但版本控制工具通常不负责此活动。您正在寻找的是可以与 Subversion 交互的活动/问题/变更管理工具。

为此，我们在我的工作地点使用 Jira，并将它与 Subversion 链接。 Jira 提供了路线图和更改历史记录，其中包括每个版本中的问题。这些问题中的每一个都与源代码控制的变化有关。因此，您可以将源代码中的更改与发布的版本联系起来。

我认为将这两个工具分开通常会更好。尽管 Perforce 特别试图将两者联系在一起，但他们只是简单地这样做。有一些事情，比如通过电子邮件向用户发送问题更改、向问题添加 cmets、向问题添加附件，这些在 Jira 等专用软件中做得更好。另一方面，Jira 不太擅长版本控制、合并和分支源......这在 Subversion 等专门的软件中处理得更好。

为了全面披露，除了 Jira 之外，还有其他工具，例如 Bugzilla、Trac、IBM Rational Jazz 等，它们可以使用 Subversion 完成与 Jira 所做的相同的事情，但具有不同级别的功能。

【讨论】：

【解决方案8】：

看看 SVN Book 的主题：

Tags 和 Browsing the Repository

标签和分支是“写时复制”，这意味着存储库中没有额外的副本。通常，除非出于某种原因（即在分支上开发），否则单个开发人员不需要本地副本。

如果您标记每个版本，那么您可以通过浏览存储库来查看标记。上面的链接直接讨论了命令行工具，但也有像 Windows 上的 TortoiseSVN 这样的 GUI 工具。您可以获取历史记录、进行比较等。

要查看版本中所做的更改，您只需显示从您想要的标签修订版到前一个标签修订版 +1 的主干日志。这听起来像是额外的工作，但是一旦你习惯了它就会非常简单。

使用我们的构建工具，我们还将带有一些版本号信息的文件提交回主干，并且注释具有构建的版本号。如果您的主要代码在主干中，这也可以作为构建中内容的标记（查看版本提交之间）。

【讨论】：

【解决方案9】：

我的目标是有一个单一的视图向我展示我的发行年表，在这之间我可以看到所有之间发生的代码更改每个版本。

您研究过 Tortoise SVN 修订图吗？如果您标记每个版本（正如其他人指出的那样，这不涉及在服务器或工作站上复制文件），那么您可以按时间顺序查看所有修订，标签指示实际版本。您可以通过突出显示您感兴趣的两个修订并从上下文菜单中选择差异来区分版本和/或主干。

【讨论】：

【解决方案10】：

此外，如果您知道要比较的修订版，您可以进行 SVN 比较，您将看到哪些文件已更改以及两个修订版之间的更改情况。

不确定您的总体设置，但有人提到 TortoiseSVN。这绝对是一个好的开始。我个人将 Eclipse 与 subclipse 插件一起使用，它允许我在修订之间的图形环境中执行差异。只要您有您的项目，您就可以将任何修订与任何其他修订进行比较，因此您不需要进行所有类型的文件复制。

此外，我们通常在每个存储库中设置三个目录。分支、树干和标签。正如有人指出的那样，标签专门用于识别版本。

【讨论】：

【解决方案11】：

仅供参考，

SVN 副本不是硬拷贝，它只是链接，因此除了更改的文件之外不会占用任何空间。无论如何，这些版本都会占用空间。因此，为每个版本创建一个副本不会占用任何空间。

【讨论】：

我知道SVN副本只是链接。这不是重点 - 重点是当我想查看修订之间的更改时，它并没有真正帮助我。

【解决方案12】：

将主干复制到 svn 存储库中的标签路径是实现此目的的方法。它是一个 svn 副本，因此不会在 svn 存储库服务器上出现重复文件。如果您选择检出除主干以外的 svn 路径，则只有在本地有重复文件。提交这些工作副本然后返回到它们被签出的 svn 路径。

这本质上是svn中分支的特定常规实现。查看在线 svn book 了解更多详情。

【讨论】：

哦，对于lazyweb用户，在线svn书在svnbook.red-bean.com
我不相信分支会在这里帮助我，原因在我的问题编辑中阐明了

【解决方案13】：

标记将是在制作发布标签时写入的提交消息（到 /tags 的 svn 副本）。至少这是最常用的方法。

【讨论】：

你能告诉我更多关于这个提交消息 jor 的信息吗？
这是我为一个项目所做的。构建机器将更新文件并在提交消息中插入构建号/版本。