How to default svn:keywords to enabled?

Question

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?

Lithium

Answer 1

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.

Erskine

Answer 2

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.

Duck

for newer windows OS's, the config file might be in C:\Users\ user \AppData\Roaming\Subversion – Uneventful

Answer 3

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 $

Larkin

Agreed - I think developers who compile executables from directory structures sometimes forget about this kind of scenario, where there may have been incremental patches, environments may have been copied from production at various times and so on, and it is enormously useful to be able to see the actual branch and revision information at a glance. Yes there should be a robust deployment process in place, yes it's always possible the code was edited post-deployment (though you'd certainly hope not), but there's nothing like having automatically generated info right there in the source. – Mcglone