我还在学习TortoiseSVN 1.6,到目前为止,我无法设置关键字,因此一旦运行了commit命令,它们就会在文件中更新。
我右键单击文件/目录>属性>新。我从下拉菜单中选择svn:keywords
,然后在属性值字段中添加$Author$
$ID$
$HeadURL$
$Revision$
和$Date$
。
我还通过右键单击桌面>添加这些内容。设置> Subversion配置文件。从这里开始,我已经取消注释了enable-auto-props = yes
并添加了以下两个条目:
*.cfc = svn:keywords=HeadURL Revision Author Date ID
*.cfm = svn:keywords=HeadURL Revision Author Date ID
我的文件是基本文本文件,包含以下内容:
在我提交存储库之后,这些关键字没有更新,所以我不确定我在这里做错了什么。
答案 0 :(得分:1)
在您的文本文件中,您只需要执行此操作:
$Revision$
$Author$
当Subversion执行结帐时,它会将其更改为:
$Revision: 1234$
$Author: Quimby$
无需先为关键字加上标题。
如果您希望Subversion扩展关键字,则必须设置svn:keywords
。您必须将svn:keywords
属性的值设为 裸 关键字,用空格分隔, AND 正确套装。它必须是$Id$
而不是$ID$
。
换句话说,您的svn:keywords
属性应设置为:
Revision Author Date Id
而不是
$Revision$ $Author$ $Date$ $Id$
此外,我将推出此版本的最终用户是否必须编辑他们的Subversion配置文件,或者只担心在他们的WC中设置文件/目录上的关键字?
由于svn:keywords
是一个属性,因此它将在所有工作副本中设置。任何结帐的人都会看到扩展的关键字。
问题是如果有人添加了新文件会发生什么,并且您也希望svn:keywords
设置这些文件。在Subversion版本1.7及之前,如果这些属性未设置为文件的特定值,则必须使用预提交挂钩来提交失败。
开发人员在几次将提交拒绝后因为他们没有在文件上设置此属性而将其置于其Subversion配置的 autoprop 部分中。这样,当他们添加新文件时,Subversion会自动添加属性。
在Subversion 1.8中,引入了可继承属性。两个主要的是svn:autoprop
和svn:global-ignores
。这两个属性可以替换User配置中的 global-ignores 和 autoprop 部分。这是一种可以为整个存储库执行此操作的方法,而无需担心用户的配置。
然而,关键字并没有那么有用。它们通常会产生比光更多的痛苦(而$Log$
则是彻头彻尾的邪恶)。
关键字为您提供哪些信息?如果您在工作副本中,只需运行Subversion命令即可获得关键字所具有的所有信息。
在工作副本之外,关键字通常会在编译阶段消失。即使您将关键字嵌入到字符串中,它也只是该文件的那个版本,并且不会告诉您其余的文件版本。更好的方法是嵌入一个对您有意义的版本字符串。例如,整个程序的版本号。如果您使用像Jenkins这样的CI系统,这很容易做到。实际上,在编译代码时,我们嵌入了Jenkins项目和内部版本号(以及工作副本的修订版)。
它可能在脚本中更有用,但它很容易欺骗。想象一下Python脚本,该脚本在文件中嵌入了该Python脚本的修订版。发现了一个错误,有人修改了该文件。嵌入式关键字现在具有误导性。我们假设需要在此脚本中添加新功能。开发人员查看脚本上的修订号,检查它,添加功能,然后将新版本提供给客户。现在,原始的bug又回到了程序中。
这就是为什么许多版本控制系统已经删除了关键字,如果它们确实拥有它们,则必须为每个文件一次打开一个。它们可能会导致编译问题(在SCCS中尤其如此,其中关键字是由%
符号包围的单个字母,导致一些意外扩展事件),它们可能误导,并且在现代版本控制系统中,不是&# 39;必要的。
在将关键字嵌入所有文件之前,请仔细考虑您的策略。
答案 1 :(得分:0)
应用于目录的自动道具和属性(要应用于子项)仅在文件添加到工作副本时应用于文件。如果您尝试将这些关键字应用于已经版本化的文件,则需要将它们分别应用于这些文件。