提交或推送到 kiln 时自动标记变更集
我想知道是否有一种方法可以在本地提交或推送到 kiln 存储库时自动标记变更集。
我希望每个变更集都有一个带有版本/内部版本号的标签。我计划将我的版本/内部版本号存储在数据库中，并希望有一个脚本从数据库中检索该值并将标签添加到变更集中。是否可以自动调用脚本来将其作为提交后事件或推送到 kiln 存储库时的推送后事件来执行？
我也愿意接受任何其他方法来实现每次提交/推送的自动标记。
I would like to know if there is a way to automatically tag a changeset as it is committed locally or when pushed to the kiln repository.
I would like every changeset to have a tag with version/build number. I am planning to store my version/build numbers in a database and would like to have a script retrieve this value from the database and add a tag to the changeset. Is it possible to invoke a script automatically to do this as a post-commit event or as a post-push event when pushed to the kiln repository?
I am also open to any other approaches to achieve automatic tagging on every commit/push.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
与其为每个变更集创建标签，为什么不尝试以下方法之一：
可以使用以下命令从日志中生成描述性字符串：
结果采用以下形式：
例如，在 Mercurial 存储库的本地克隆上，会生成：
这告诉我自标签 1.7.2 以来已经有两次提交，并且当前变更集哈希是 5e51254a。
在 Mercurial 中，每个标签都会创建一个新的变更集。因此，如果您为每个提交添加标签，那么存储库中的变更集数量就会增加一倍。您应该使用内置工具（如上所述）而不是尝试重新创建轮子。
Rather than creating a tag for each changeset, why not try one of the following:
A descriptive string can be generated from the log using this command:
The result takes the form:
For example, on my local clone of the Mercurial repo, this generates:
Which tells me that there have been two commits since tag 1.7.2 and the current changeset hash is 5e51254a.
In Mercurial, each tag creates a new changeset. So if you tag every commit, you double the number of changesets in the repo. You should use the built-in tools (as described above) rather than try to recreate the wheel.
您始终可以编写一个提交后挂钩来执行此操作。
标签对于识别提交历史记录中的重要时刻很有用。为这些时刻提供一个与产品开发相关的有意义的名称，例如版本 1.0、版本 1.3 等。
如果您要为每个更改集制作一个标签，那么您只会增加噪音水平。您仍然需要在某个地方保留有关重要标签的信息。
将标签视为有关变更集的元信息。并非所有这些都值得同等重视。并非所有这些都需要元信息。
只有当您谨慎使用标签时，查看标签才能为您提供有意义的历史记录。
请参阅：
示例：通过推送、拉取添加变更组后运行或解绑。我用它来触发自动构建。
同样，还有 post-commit 、 post-push hooks
You could always write a post commit hook to do that.
Tags are useful to identify important moments in your commit history. Providing those moments a meaningful name that relates to the product development like release 1.0, release 1.3 etc .
If you were to make a tag every change set then you would just increase noise level. You will still need to keep information about important tags some where.
Consider tag as meta information about change-sets. Not all of them deserve the same importance. Not all of them require that meta information.
Looking at tags can give you meaningful history only when you use them sparingly.
See:
Example: Run after a changegroup has been added via push, pull or unbundle. I have used it to trigger automatic builds.
Similarly, there is post-commit , post-push hooks