Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to default svn:keywords to enabled?

Is there a way to enable svn:keywords by default so that this property does not need to be turned on for each keyword every time a new source file is added?

like image 899
jacknad Avatar asked Sep 08 '11 14:09

jacknad


3 Answers

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.

like image 122
Daniel Trebbien Avatar answered Nov 04 '22 21:11

Daniel Trebbien


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.

like image 30
David W. Avatar answered Nov 04 '22 23:11

David W.


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,'$')-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:

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 $
like image 1
JRex Avatar answered Nov 04 '22 22:11

JRex