SVN：提交后挂钩：将文本添加到评论字段答案

【问题标题】：SVN: post-commit hook: adding text to comment fieldSVN：提交后挂钩：将文本添加到评论字段
【发布时间】：2014-09-26 19:09:40
【问题描述】：

当我提交到 repo（从 TSVN 到 VisualSVN 服务器）时，我想在评论中添加我正在提交的文件之一的版本。

例如，我要提交的文件版本号（不是 svn 修订版）是 4.0.56.896。我希望这个提交文件的版本号出现在评论/消息字段中。这将很有用，因为现在如果我想读取文件版本号，对于给定的 svn 修订，我必须从 repo 中签出修订，然后他们会转到文件属性来读取它。

文件版本号已知。可以通过执行exe文件获取，也可以从文本文件中获取存储后拉取。

但是如何将它添加到 post-commit 钩子脚本的评论中？

编辑：

澄清：

我要处理的问题是：

我想快速了解在某个修订版提交的 .dll 文件的版本。

例如，作为提交的结果，修订号是 r1235。在这个版本中，假设我提交了一个文件 dll1.dll @ VERSION 4.0.56.896。然后我对 repo 做了另一个提交。假设在这些提交之后我处于修订版 r1490，我需要检查 dll1.dll 文件的版本是什么。我现在这样做的方式是将 WC 更新为修订版，然后右键单击该文件并从那里读取。

所以，我认为最好准备一个提交后挂钩，将有关 dll1.dll 文件的 VERSION 信息放在 Comment/Message 框中，以避免“将 WC 更新为修订版”操作。

【问题讨论】：

标签： svn tortoisesvn visualsvn-server

【解决方案1】：

首先是一个直截了当的答案..

为了更改提交注释，您必须设置另一个 pre-revprop-change 挂钩以允许更改修订属性。允许对修订属性进行重大更改可能是一种危险的做法，因为用户可以更改谁以及何时提交了更改。这就是为什么不允许开箱即用更改修订属性的原因。

所以，首先创建一个pre-revprop-change 挂钩。示例脚本在 Subversion 存储库目录的 hooks 目录中以 pre-revprop-change.tmpl 给出。它只允许更改svn:log 修订属性，但不验证它是否是同一用户。

一旦您创建了这样的钩子，添加一个更改提交注释的提交后钩子就相当简单了。 $REVISION 和 $REPO 传递给 post-commit 钩子，您只需通过svn pg --revprop svn:log -r $REV $REPO 获取提交消息，然后修改它，并通过svn ps svn:log --revprop -r "$commit_msg" $REV 设置提交消息。

回到你的原始问题：

当我提交到 repo（从 TSVN 到 VisualSVN 服务器）时，我想在评论中添加我正在提交的文件之一的版本。

那个版本是什么？如果是 Subversion 版本，我不会打扰。如果有一些 version.txt 文件，你可以从那里拉它。如果每个文件都有不同的版本，那么如果你提交多个文件并且每个文件都有不同的版本，那么你只会增加混乱。

您遇到了什么问题，这是解决该问题的最佳方法吗？解释一下，我可能会给你一个比试图在运行中操纵提交评论更好的答案。

更好的答案

您想要的是找到您发布给客户的内容的方法。客户的版本为 4.0.56.896，您希望能够找到该特定版本。

这就是标记的用途。当你向客户发布你的软件时，你应该给它贴上标签。哎呀，您甚至可以将其标记为 4.0.56.896。找到标签比搜索日志然后尝试弄清楚您是否检查过它要快得多。您也不必担心更改提交 cmets。

实际上，您需要更好地控制构建和发布过程。每个版本都是客户可能拥有的吗？你做任何测试吗？是否有发布时间表，或者您是否在追逐错误并不断灭火？

这就是变更控制的全部内容。我建议您查看Jenkins 以帮助您的构建过程。 Jenkins 将在每次更改时自动构建和测试您的代码（如果您愿意，也可以按计划进行）。您可以跟踪项目的历史，甚至跟踪构建的状态。例如，当构建从开发测试转移到 QA 测试再到 UAT 测试时，我们会更改构建描述。它可以帮助我们跟踪正在发生的事情。我们甚至通过 Jenkins 进行标记。

Jenkins 还可以保存您的构建产品，因此您无需将它们签入 Subversion。（请告诉我，您没有将构建的二进制文件签入 Subversion。这是另一种不好的做法。）。您还可以将NuGet 集成到您的构建过程中。（NuGet 可帮助您打包可重用的 DLL 或 .NET 生成的任何内容，因此您可以在其他项目中使用它们。

【讨论】：

David - 您的解决方案会起作用，但从常识来看它很糟糕，因为它无法修复损坏的工作流程。 OP 不会在（非文本）自己的产品中存储任何 VCS 元数据，并且希望以相反的顺序检测存储库中的关系“文件版本”-“修订”（根据客户需求，AFAICS）
我现在看到 OP 在我给出答案并提供更多细节后改变了问题。我知道我的解决方案远非 ..uh.. 最佳。这就是为什么我告诉OP“这是解决问题的最佳方法吗？解释一下，我可以给你一个更好的答案”
标记只是（良好的完整）解决方案的一部分，如果客户可以并行使用一定数量的版本，并且您必须报告错误i> 知道，客户端的哪个版本的应用程序产生了麻烦
@user1146081 Jenkins 或 NuGet 会帮助您解决问题吗？您不应该将编译后的代码存储在 Subversion 中。这不仅是一种糟糕的 CM 做法，而且会使 repo 大大膨胀。您很快就会发现您的 repo 大小为 +20Gb，并且由您不再关心的 99% 已编译代码组成。将发布存储在发布存储库中。我们将发布的编译代码存储在 Jenkins 构建中。
DavidW：我主要使用repos来存储编译好的LabVIEW模块。我无法从编译版本中分离源代码。我没有办法摆脱这种情况。无论如何，我正在调查 Jenkins。

【解决方案2】：

虽然大卫的回答在技术上是正确的...

在你存储文件版本作为文件的特殊subversion-property，你可以直接从URL获取它，无需结帐，仔细阅读svn help pg

只是存储库文件中存在的示例（我没有其他属性并且懒得创建示例存储库）

>svn pg svn:keywords "^/trunk/Scartel-Yota.ini"
Date Revision Author Id

即使在工作流中添加附加层的现有可能性也不是 DBW 的借口（“该死的破碎工作流”）：为什么，如果您必须从文件中获取有关该文件在存储库中的修订的信息，您只是不存储这个数据而不是文件版本或其他（特殊？）字段中的无用废话。大多数项目（我可以监控）在开发中使用 VCS 使用“文件版本”字段中的最后一个八位字节来存储（Subversion）修订版

示例 1

>wmic datafile where Name="FlylinkDC.exe" get Version
Version

7, 7, 503, 17574

和17574 是这个文件的编译版本

示例 2

>wmic datafile where Name="TortoiseProc.exe" get Version
Version
1.8.8.25755

我假设 25755 是修订版，但是这个数据（完全）添加到关于屏幕中以便于识别使用的应用程序版本

TortoiseSVN 1.8.8，内部版本 25755 - 32 位，2014/08/10 14:44:06

【讨论】：