5

考虑软件分布在两个独立的存储库 Pub 和 Priv 中。Pub 存储库是公开的。私人已关闭。当任何一方发生变化时，持续集成服务器会同时构建 Pub 和 Priv。然后它从 Priv 创建可供 Pub 用户使用的可下载二进制文件。这些二进制文件在内部和带有颠覆修订的文件名上标记。

问题是：如何让从 Pub 构建的程序知道正确的、相应的 Priv 修订号，以便它们可以自动下载和运行？

当前的解决方案是让构建服务器修改 Pub 中的文件以设置 Priv 的修订号并将这些更改提交给 Pub。然而，这带来了两个重大问题：

  1. 构建需要很长时间，因此如果有人在构建过程中提交对 Pub（或 Priv）的更改，则会产生冲突。这可以强制解决，但日志历史看起来很奇怪，好像这些修订版已进入该版本。

  2. 颠覆日志有许多条目，例如“自动构建更新了版本”。每次构建运行都会污染其他信息丰富的颠覆日志。

那么我们能否以一种不需要更改存储库的方式来做到这一点。

真诚的，韦恩

4

3 回答 3

2

您可以使用修订属性（请参阅标题为“未版本化属性”的部分）来存储 Priv 的适当修订与 Pub 的适当修订。修订属性的好处是它们不需要提交 - 因此没有历史污染。

用 Subversion 的说法，修订属性附加到特定修订而不是版本化文件夹。与附加到文件或文件夹的属性不同，这些属性是非版本化的。他们只是立即被应用。使用 --revprop 开关添加修订属性到“svn propset”。在 TortoiseSVN 中，它们是通过历史日志添加的（右键单击修订，然后选择“显示修订属性”）而不是文件或文件夹的属性，并且无需提交即可立即应用。

例如，要将 Priv 的 r1234 与 Pub 的 r6789 关联，您可以从 Pub 的结帐中执行此操作。

svn propset --revprop -r6789 "priv:version" "1234"

现在，当构建 Pub 的 r6789 时，您可以执行此操作

svn propget --revprop -r6789 "priv:version"

检索 Priv 的适当修订号。为了应对在最后一次 Priv 构建之后发生的其他提交，您的脚本将不得不“遍历”历史，询问每个修订版本的“priv：version”，直到您获得一个值。或者你可以有一个 post-commit 钩子，当它发生时将属性复制到每个修订版。

不过有一个问题。您需要有一个 pre-revprop-change 钩子，它允许您使用修订属性。最简单的方法是让它始终返回 0，因此允许任何 revprop。在 Windows 上，我只是在 hooks 目录中创建一个空的“pre-revprop-change.bat”文件。如果您查看创建属性时提供的示例钩子脚本，它实际上已经很好地记录在案。

于 2009-11-06T10:27:45.910 回答
0

我可以想到几种方法来做到这一点。我认为由于某种原因，不可能使修订号直接相互对应，这将是显而易见和最简单的解决方案。

一种方法是使用 Pub 的提交消息来包含指向相应 Priv 修订版的指针，例如“Corresponds to Priv r1234”。

另一种方法是将对应关系存储在存储库之外，在一些简单的数据库甚至文本文件中，每当来自 Priv 的提交被推送到 Pub 时就会更新。

另一种方法是不要像您目前所做的那样进行单独的提交来记录 Priv 修订，而是将该更改添加到应该记录的提交中。

于 2009-11-06T09:56:16.643 回答
0

抱歉，stackoverflow 不允许自己回复或编辑我的帖子或您的答案，因为我在问这个问题时没有注册。所以这里有回应...

西蒙：谢谢。为什么你建议修订属性不需要提交？nant 构建脚本当前使用修订属性来跟踪分支版本以进行合并和重新集成（svn 的内置合并功能太容易混淆）。但是这些修订属性需要提交到中央存储库，并且您的链接指的是用于此的相同类型的修订属性。您是指其他类型的修订属性吗？

关键技能：是的，提交“自动构建更新到版本 0.5.6.1049”的消息是可自定义的。该提交实际上发生在 nant 构建脚本中，该脚本由 CI 使用 Hudson 执行。而且，请记住，我们希望消除该提交，因为每次对 Pub 的提交都会跟随一个（或多个）污染日志的自动消息。

标记：重新：提交指向 Priv 的指针。提交 pub 的用户对 Priv 的访问权限为零，因此他们不知道是什么版本——否则是个好主意。另一方面，自动构建现在在构建 pub 和 priv 时执行此操作，但是这会污染日志文件，大量自动提交只是为了将版本链接到 Priv 没有任何其他实质性更改。

Mark：我们考虑将通信存储在存储库之外，但这会导致另一个我们无法解决的问题。解决这个问题，你就赢得了答案。问题是 pub 存储库包含依赖于从 Priv 构建的具有完全对应版本的二进制文件的软件。因此它包含一个“自动更新”功能，该功能连接到持有 Priv 的服务器，并要求提供二进制文件列表并下载它们。关键是开始这个​​下载的主要参数是版本。

马克：所以问题是 Pub 怎么知道要下载哪个版本？现在，原始问题中的情况解决了这一问题。自动构建 nant 脚本对 Pub 中的源代码进行了更改，以包含 Priv 的版本号，但这就是用“自动构建更新版本..”污染 Pub 日志的原因。如果 priv 从 Web 服务器请求 Priv 二进制文件，则自动更新工具使用该版本。这一切都有效。

马克：起初，次要问题似乎可以通过切换关系来解决，让 Pub 软件使用它的版本自动更新 - Pub 的版本 - 并且 Web 服务器使用单独的文件匹配它以获取最新的Priv 二进制文件的匹配版本。然而，看起来，似乎没有实用的方法让 Pub 软件从每次提交中知道版本。

马克：如果你把 $Rev$ 关键字放在自动更新代码中，它只会在文件被修改时才会更新。在使用 Subversion 时，这似乎是一个“古老的”挑战。似乎预提交挂钩可以使用版本更新源代码，但似乎只有有人提交有问题的自动更新源文件才有效。

马克：你的最后一个想法有点令人困惑，但听起来就像刚才提到的在提交到 Pub 时包含版本信息而不是额外的自动提交。我喜欢这样，但无法弄清楚（在谷歌搜索和阅读论坛和帖子超过一天之后）。如何提交项目范围的版本以及对 Subversion 的任何普通提交似乎是一个常见的挑战，因为它只单独版本文件。即使您在预提交挂钩中使用 svnversion ，它也只会更新已修改的文件，对吗？那么自动构建源代码是如何知道运行时是什么版本的呢？

大家：感谢大家的提问和回复。它有助于缩小对问题的理解范围，以便我们找到解决方案！太酷了！

于 2009-11-08T15:56:04.590 回答