【发布时间】:2009-07-13 15:08:43
【问题描述】:
我有一个 SVN 存储库,以这种格式检查文件。
<filename>.<ext>-rev<revision number>
在另一个文件中输入了修订号。构建完成后,将解析该文件,并获取具有相应修订号的文件并将其重命名为标准文件名
如何在提交前获取SVN的changelist编号?
【问题讨论】:
标签: svn tortoisesvn
我有一个 SVN 存储库,以这种格式检查文件。
<filename>.<ext>-rev<revision number>
在另一个文件中输入了修订号。构建完成后,将解析该文件,并获取具有相应修订号的文件并将其重命名为标准文件名
如何在提交前获取SVN的changelist编号?
【问题讨论】:
标签: svn tortoisesvn
我认为您误用了版本控制系统 (VCS)。使用 VCS 时,您不需要将修订号或日期放入文件名。 VCS 将自动为您存储该信息,作为元数据。
您应该替换旧文件,而不是每次都使用新的修订/日期签入新文件。如果您出于某种原因需要旧文件,它们将始终在 VCS 历史记录中可用。除了减少混乱之外,这还具有始终保持相同文件名的优点,这使得自动化更容易。
此外,作为一般规则,您不希望将已编译的二进制文件提交到源代码树。您应该只提交构建二进制文件所需的文件(即源文件和 makefile)。
如果您真的想继续当前的计划,您将会遇到困难。在提交成功之前,无法知道您将获得什么修订号——这是原子提交概念的基本设计保证。您可以做的最好的事情是添加一个提交后挂钩,该挂钩检查刚刚提交的任何内容的副本并将文件重命名为修订号。
这意味着文件的名称更改将反映比发生名称更改的版本更早的版本,但它允许您使文件名修订号与您所做的更改相同,我想就是你想要的。这种技术还将导致每次更改都提交两次。不推荐。
【讨论】:
在执行提交之前没有安全的方法来获取修订号。这将要求客户端能够锁定存储库。
为什么要为每个新修订签入一个新文件?对于您要解决的问题,我确信有更好的解决方案。
【讨论】:
您可以尝试执行svn up 并获取最新版本并使用该版本加一。但正如 Mark Dickinson 所说,如果其他人更新会有问题。
我会尝试不同的方法。
【讨论】:
我想我现在掌握了全貌。
场景是这样的:
一些代码是从存储库的不同分支签出的。进行修复,并将产生的更改提交到该存储库(签入时获得修订号)。
通过这些更改创建一个二进制文件(库)。这个库是一个更大模块的一部分,这个二进制文件作为
【讨论】:
查看当前可用的“SvnRev”:
http://www.compuphase.com/svnrev.htm
听起来您正在尝试实现某种 CHANGELOG 或发布标记系统,用户可以在其中选择不同的发布版本。所以,假设这就是你在这里寻找的东西,这就是我在类似情况下所做的。我知道你的问题已经有一年了,但也许其他人会发现这个。
我维护了一个单独的文件来存储特别感兴趣的修订历史。我有一些项目,我为我们的整个应用程序制作了一个“官方”安装程序。通常我不会将生成的代码存储在版本控制系统中,但是我们将这些二进制文件视为特殊的。我们喜欢保留我们交付给用户的确切二进制文件。我们不想以后重建它们,将它们存储在 SVN 中是对版本控制的方便滥用......
所以我构建了我的安装程序二进制文件;将安装程序二进制文件提交到 SVN;获取我刚刚提交的安装程序的 SVN 版本;将修订/日期/注释附加到名为 CHANGELOG 的文件中;最后我提交了 CHANGELOG 文件。 CHANGELOG 的修订号会比安装程序多一个或多个,但我只关心安装程序的修订号。
为了更加方便,安装程序被复制到网络服务器并放置在以安装程序修订号命名的目录下。但是我们总是可以查看 CHANGELOG 注释以找到我们想要的安装程序的修订版,并通过该修订版进行检查。
我们还可以使用该修订号来签出用于构建安装程序的源代码(您必须确保在您的源代码签出/构建和安装程序提交之间没有人提交更改)。如果你真的不介意浪费磁盘空间,你可以做一个标签;建造;并将安装程序提交回标签。当然,SVN 并没有真正的标签,所以你会做一个“svn 复制”;但是一个真正的标记系统不会让你将更改提交回它。
【讨论】: