如何在每次提交时提交 subversion 修订版,以便在两个存储库之间进行引用

发布于 2024-08-10 10:22:25 字数 523 浏览 6 评论 0原文

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

问题是:如何让从 Pub 构建的程序知道正确的、相应的 Priv 版本号,以便它们可以自动下载和运行?

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

  1. 构建需要很长时间,因此如果有人在构建期间向 Pub(或 Priv)提交更改,则会产生冲突。这可以强制解决,但日志历史记录看起来很奇怪,好像这些修订已进入该构建。

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

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

真挚地, 韦恩

Consider software spread in two separate repositories, Pub and Priv. Pub repository is public. Priv is closed. An continuous integration server builds both Pub and Priv when either side changes. It then creates downloadable binaries from Priv that are available to users of Pub. Those binaries are labeled internally and on the file name with the subversion revision.

Question is: How to have programs built from Pub aware of the correct, corresponding Priv revision number so they can auto download and run?

The current solution is for the build server to modify files in Pub to set the revision number of Priv and commit those changes to Pub. However, this presents 2 significant problems:

  1. The build takes a long time so if someone commits changes to Pub (or Priv) during the build, it creates conflicts. That can be forced resolved but the log history looks odd as if those revisions made it into that build.

  2. The subversion log has many entries like "Auto build updated the version." from every time the build run which polutes the otherwise informative subversion log.

So can we do this in a way which doesn't require changing the repository.

Sincerely,
Wayne

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

一杆小烟枪 2024-08-17 10:22:25

您可以使用修订属性(请参阅标题为“未版本化属性”的部分)根据 Pub 的适当修订来存储 Priv 的适当修订,修订属性的好处是它们不需要提交 - 因此,

用 Subversion 的话说,修订属性不会附加到特定修订 。这些属性与附加到文件或文件夹的属性不同,它们只是通过使用 TortoiseSVN 中的 --revprop 开关来立即应用。它们是通过历史日志添加的(右键单击修订版,然后选择“显示修订版属性”)而不是文件或文件夹的属性,并且会立即应用,而无需进行提交,

例如,将 Priv 的 r1234 与 Pub 的 r6789 关联。您可以通过 Pub 的结帐处执行此操作。

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

现在,当 Pub 的 r6789 构建完成后,您可以执行此操作

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

来检索 Priv 的适当修订号。为了应对上次 Priv 构建后发生的其他提交,您的脚本必须“遍历”历史记录,询问每个修订版本的“priv:version”,直到获得一个值。或者,您可以使用提交后挂钩,在每个修订发生时将属性复制到该修订。

不过有一个问题。您需要有一个 pre-revprop-change 挂钩,它允许您使用修订属性。最简单的方法是让它始终返回 0,这样任何 revprop 都是允许的。在 Windows 上,我只需在 hooks 目录中创建一个空的“pre-revprop-change.bat”文件即可。如果您查看创建属性时提供的示例挂钩脚本,您会发现它实际上有很好的文档记录。

You can use a revision property (see the section entitled "Unversioned properties) to store the appropriate revision of Priv against the appropriate revision of Pub. The nice thing about revision properties is that they don't need a commit - so no history pollution.

Revision properties, in Subversion parlance, are attached to a particular revision rather than a versioned folder. These properties, unlike the properties that get attached to files or folders, are non-versioned. They just get applied straight away. Revision properties are added by using the --revprop switch to "svn propset". In TortoiseSVN they are added via the history log (right click a revision then select "Show Revision Properties") rather than the properties of a file or folder and are applied immediately without making a commit.

For example, to associate r1234 of Priv with r6789 of Pub you could do this from a checkout of Pub.

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

Now when r6789 of Pub is built you can do this

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

to retrieve the appropriate revision number of Priv. In order to cope with other commits that happen after the last Priv build your script would have to "walk" down the history asking each revision for "priv:version" until you get a value. Or you could have a post-commit hook that copies the property to each revision as it occurs.

One gotcha though. You need to have a pre-revprop-change hook that will allow you to work with revision properties. The simplest way is to have it always return 0 so any revprop is allowed. On Windows I do this simply creating an empty "pre-revprop-change.bat" file in the hooks directory. If you take a look at the example hook script that's provided when you create a property, it's actually pretty well documented.

离不开的别离 2024-08-17 10:22:25

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

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

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

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

I can think of several ways to do this. I assume that for some reason it's not possible to make the revision numbers correspond to each other directly, which would be the obvious and simplest solution.

One way would be to use the commit message to Pub to include a pointer to the corresponding Priv revision, like "Corresponds to Priv r1234".

Another would be to store the correspondences outside the repositories, in some simple database or even text file, that's updated whenever a commit from Priv is pushed to Pub.

Yet another way would be to not do a separate commit, as you currently do, to record the Priv revision, but to add that change to the commit that's supposed to be recorded.

ぺ禁宫浮华殁 2024-08-17 10:22:25

抱歉,stackoverflow 不允许我自己回复或编辑我的帖子或您的答案,因为当我问这个问题时我还没有注册。以下是回复...

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

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

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

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

Mark:所以问题是 Pub 如何知道要下载哪个版本?现在,这已通过原始问题中的情况解决了。自动构建 nant 脚本对 Pub 中的源代码进行了更改,以包含 Priv 的版本号,但这正是污染 Pub 日志的原因:“自动构建更新了版本..”。自动更新工具使用该版本的 priv 向 Web 服务器请求 Priv 二进制文件。这一切都有效。

马克:首先,第二个问题似乎可以通过切换关系来解决,让 Pub 软件使用它的 on 版本(Pub 的版本)自动更新,并且 Web 服务器使用单独的文件来匹配它以获得最新版本Priv 二进制文件的匹配版本。然而,你瞧,似乎没有实际的方法可以让 Pub 软件知道每次提交的版本。

标记:如果您将 $Rev$ 关键字放入自动更新代码中,则只有在该文件被修改时才会更新。这对于使用 Subversion 来说似乎是一个“古老”的挑战。似乎预提交挂钩可以使用版本更新源代码,但似乎只有有人提交有问题的自动更新源文件才有效。

Mark:您的最后一个想法有点令人困惑,但听起来与刚才提到的相同,即在提交到 Pub 时包含版本信息,而不是进行额外的自动提交。我喜欢这一点,但无法弄清楚(在谷歌搜索和阅读论坛和帖子一天多之后)。如何提交项目范围版本以及任何普通提交到 Subversion 似乎是一个常见的挑战,因为它仅单独版本化文件。即使您在预提交挂钩中使用 svnversion 它也只会更新修改的文​​件,对吧?那么自动构建源代码运行时如何知道是什么版本呢?

大家:谢谢大家的提问和回答。它有助于缩小对问题的理解,以便我们找到解决方案!所以太酷了!

Sorry, stackoverflow disallows replying or edit to my post myself or your answers since I wasn't registered when I asked this question. So here are responses...

Simon: Thanks. Why do you propose revision properties don't require committing? The nant build script currently uses revision properties to keep track of branch versions for merging and reintegration (svn's builtin merge ability gets confused too easily). But those revision properties require committing to make it to the central repository and your link refers to the same type of revision properties being used for this. Are you referring to some other type of revision properties?

Critical Skill: Yes, the messages for committing "Autobuild updated to version 0.5.6.1049" is customizable. That commit actually happens in the nant build script which gets executed by CI using Hudson. And, remember, we'd like to eliminate that commit because every commit to Pub gets followed by one (or more) of those automated messages which pollutes the logs.

Mark: re: Commit pointer to Priv. Users who commit to pub have zero access to Priv so they don't know what revision--otherwise a good idea. On the other hand, the automated build does this now when it builds pub and priv but that pollutes the log file with tons of automated commits simply to link the versions w/o any other substantive change to Priv.

Mark: We considered storing the correspondences outside the repositories but that leads to another problem we can't solve. Solve this and you win the answer. The problem is that the pub repository holds software which depends on binaries build from Priv with the exactly corresponding version. So it include an "auto update" feature which connects to the server holding Priv and asks for alist of binaries and downloads them. The key is that the primary parameter to start this download is the version.

Mark: So the question is how can the Pub know which version to download? Right now that is solved to by the situation in the original question. The auto build nant script commits a change to the source code in Pub to include the version number of Priv but that is what pollutes the Pub logs with "Auto build updated the version ..". The auto update tool uses that version if priv to request from web server the Priv binaries. And it all works.

Mark: The secondary problems seems, at first, to be solvable by switching the relationship to have Pub software auto update using it's on version--the version of Pub--and the web server matches it using a separate file to get the most recent matching version of Priv binaries. However, low and behold, there seems to be no practical way to have Pub software know the version from every commit.

Mark: If you put $Rev$ keyword in the auto update code, it only gets updated it that very file was modified. This seems to an "age old" challenge in working with Subversion. It seems a pre-commit hook could update the source code with a version but it seems that only works is someone commits the auto udpate source file in question.

Mark: Your last idea was a little confusing but it sounds like it the same as just mentioned to include the version information with the commit to Pub rather than have an additional automated commit. I like that but can't figure out (after googling and reading forums and posts for more than a day). It seems like an common challenge of how to commit the project wide version along with any ordinary commit to Subversion since it only versions files individually. Even if you use svnversion in a pre-commit hook it only updates the files modified, right? So how does the auto build source code know what version when it runs?

Everyone: Thanks to all of you for your questions and responses. It helps to narrow down the understanding of the question so we can arrive at a solution! S.O. is way cool!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文