如何默认启用 svn:keywords？

发布于 2024-12-03 14:09:13 字数 59 浏览 1 评论 0原文

有没有办法默认启用 svn:keywords ，这样每次添加新源文件时就不需要为每个关键字都打开该属性？

原文

分享到QQ

分享到微博

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

发布评论

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

少年亿悲伤 2024-12-10 14:09:13

是的，使用 Subversion 自动属性：http://www.dcepler.net/post。 cfm/subversion-auto-properties

[auto-props] 部分的每个条目都是一个文件 glob，后跟 Subversion 属性，只要与该 glob 匹配的文件为 添加了。例如，如果您希望所有 CPP 文件默认具有一组特定的属性，请按照 http://www.dcepler.net/post.cfm/subversion-auto-properties 并根据您的喜好修改以下行：

*.cpp        = svn:eol-style=native; svn:keywords="Author Date Id Rev URL"; svn:mime-type=text/plain

请注意，如果您使用 svn add 添加文件 并随后启用自动属性，自动属性不会应用于添加的文件。自动属性仅应用于启用自动属性后添加的文件。

Yes, with Subversion auto properties: http://www.dcepler.net/post.cfm/subversion-auto-properties

Each entry of the [auto-props] section is a file glob followed by the Subversion properties to automatically apply whenever a file matching the glob is added. For example, if you want all CPP files to have a certain set of properties by default, then follow the instructions on http://www.dcepler.net/post.cfm/subversion-auto-properties and modify the following line according to your preferences:

*.cpp        = svn:eol-style=native; svn:keywords="Author Date Id Rev URL"; svn:mime-type=text/plain

Note that if you added files with svn add and subsequently enabled auto properties, the auto properties will not be applied to the added files. Auto properties are applied only to files that are added after auto properties are enabled.

回复收藏 0 原文

假情假意假温柔 2024-12-10 14:09:13

如上所述，您可以使用自动属性来执行此操作，但您应该问自己一个大问题：

为什么要使用关键字？

当您进行开发时，您可以轻松地使用各种 svn 命令来获取将存储在关键字中的任何信息，因此这确实没有必要。

有些人声称，一旦软件出现在客户站点上，关键字就是必要的，但是有更好的机制可以用来验证您正在使用的软件的版本。例如，在编译过程中，您可以创建一个具有更有意义的修订 ID（可能是发行号和构建日期）的文件，并将其显示为“关于框”。 ID更有意义。

我还知道我不能信任客户站点中可能存在的 shell 脚本中包含的关键字。 shell 脚本可能会显示修订号，但 shell 脚本可能已被编辑。

如果您真的非常需要这个，并且需要在您的网站上强制执行，那么您将需要一个预提交触发器，以便在关键字属性不在文件中时失败。只能为客户端设置自动属性。这意味着您必须确保每个开发人员都拥有这套工具。每次他们获得一台新计算机时，您都必须再次验证。

也不保证该财产已记录在案。存储库中的较旧文件即使经过编辑也不会神奇地添加。（仅当文件添加到存储库时才添加自动属性）。也没有什么可以阻止开发人员删除它。或者，在设置中编辑其自动属性。

您必须使用预提交触发器来保证 svn:keywords 属性位于每个需要它的文件上，并且设置正确。预提交挂钩将简单地拒绝提交未设置此属性的事务。开发商将被迫增加房产。经过一番抱怨后，开发人员将设置他们的 Subversion 客户端以使用自动属性并自行维护。

我只是碰巧有一个可以强制执行此操作的预提交触发器。该触发器是用 Perl 编写的，但只需要标准模块，因此很容易设置。您可以将其配置为说明哪些文件需要该关键字以及应该将其设置为什么。如果正在提交文件并且未将 svn:keywords 属性设置为正确的值，则提交将失败，并且错误消息将解释提交失败的原因以及开发人员需要执行的操作。

As mentioned above, you can use auto-properties to do this, but you should ask yourself one big question:

Why do you want to use Keywords?

When you are doing development, you can easily use the various svn commands to get you any information that would be stored in the keywords, so this really isn't necessary.

Some people claim that keywords are necessary once the software is on the customer site, but there are better mechanisms to use for validating what revision of your software you are using. For example, during the compilation, you could create a file with a more meaningful revision ID (Maybe the release number and build date) and display this as sort of an "about box". The ID is more meaningful.

I also know I can't trust the keywords contained in shell scripts that might be in a customer site. The shell script might say a revision number, but the shell script could have been edited.

If you really, really need this, and it's something that needs to be enforced on your site, you'll need a pre-commit trigger to fail when the keyword property is not on a file. The auto-properties can only be set for a client. That means you have to make sure each of your developers have this set. Every time they get a new computer, you'll have to verify it again.

Nor, does it guarantee that the property is on the file. Older files in the repository won't have it magically added even if they're edited. (Auto-properties only added when the file is added to the repository). There's nothing that prevents the developer from removing it either. Or, editing their auto-properties in their setup.

You have to use a pre-commit trigger to guarantee that the svn:keywords property is on each and every file where it's required and that it is set correctly. The pre-commit hook will simply refuse to commit a transaction where this property isn't set. The developer will be forced to add the property. After some griping, developers will setup their Subversion client to use auto-properties and maintain it themselves.

I just happen to have a pre-commit trigger that can enforce this. The trigger is written in Perl, but requires nothing but standard modules, so it's easy to setup. You can configure it to say which files require the keyword and what it should be set to. If a file is being committed and it doesn't have the svn:keywords attribute set to the correct value, the commit will fail, and the error message will explain why the commit failed and what the developer needs to do.

回复收藏 0 原文

水波映月 2024-12-10 14:09:13

在我们的 PL/SQL 程序（和 SQL 脚本）中存储 SVN 关键字为开发流程和系统完整性增加了重要价值。当更改发送到生产时，它会通过 Revision 关键字进行跟踪和管理。在实现此操作之前，移动文件并确保部署正确的文件的过程非常容易出错。此外，我们可以询问数据库的版本数据（参见下面的 SQL）。

  --
  ---------  Begin Version Control Data----------------------------------------
  -- $LastChangedDate: 2014-06-27 13:45:09 -0500 (Fri, 27 Jun 2014) $
  -- $Revision: 1750 $
  -- $LastChangedBy: kilarvk $
  -- $URL: svn://jdcsubv01/SQL/JDC/Trunk/JDC_UTIL.pks $
  ---------  End Version Control Data -----------------------------------------
  -- 

--select SVN Keyword Info
SELECT OWNER,
       NAME,
       TYPE,
       SUBSTR(TEXT,INSTR(TEXT,'
例子：
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $LastChangedDate: 
2014-04-08 15:33:38 -0500 (Tue, 08 Apr 2014) $
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $Revision: 1445 $
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $LastChangedBy: vamsisx $
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $URL:svn://jdcsubv01/SQL/JDC/Trunk/API_TESTER_AGNT.prc $

)-1) AS KEYWORD
FROM ALL_SOURCE 
WHERE OWNER = UPPER(NVL('&owner',OWNER))
   AND NAME = UPPER(NVL('&&pgm_name',NAME))
   AND (text LIKE '%$Revision%'
     OR TEXT LIKE '%$URL%'
     OR TEXT LIKE '%$Id%'
     OR TEXT LIKE '%$LastChanged%')

例子：

Storing SVN Keywords in our PL/SQL programs (and SQL scripts) has added significant value to development processes and system integrity. When a change is sent to production, it is tracked and managed by the Revision keyword. Before implementing this, the process of moving files, and ensuring that the correct file was being deployed was very error prone. In addition, we can interrogate the database for version data (see SQL below).

  --
  ---------  Begin Version Control Data----------------------------------------
  -- $LastChangedDate: 2014-06-27 13:45:09 -0500 (Fri, 27 Jun 2014) $
  -- $Revision: 1750 $
  -- $LastChangedBy: kilarvk $
  -- $URL: svn://jdcsubv01/SQL/JDC/Trunk/JDC_UTIL.pks $
  ---------  End Version Control Data -----------------------------------------
  -- 

--select SVN Keyword Info
SELECT OWNER,
       NAME,
       TYPE,
       SUBSTR(TEXT,INSTR(TEXT,'
Example:
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $LastChangedDate: 
2014-04-08 15:33:38 -0500 (Tue, 08 Apr 2014) $
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $Revision: 1445 $
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $LastChangedBy: vamsisx $
JDCSCHEMA   API_TESTER_AGNT PROCEDURE    $URL:svn://jdcsubv01/SQL/JDC/Trunk/API_TESTER_AGNT.prc $

)-1) AS KEYWORD
FROM ALL_SOURCE 
WHERE OWNER = UPPER(NVL('&owner',OWNER))
   AND NAME = UPPER(NVL('&&pgm_name',NAME))
   AND (text LIKE '%$Revision%'
     OR TEXT LIKE '%$URL%'
     OR TEXT LIKE '%$Id%'
     OR TEXT LIKE '%$LastChanged%')

Example:

回复收藏 0 原文

~没有更多了~