Any source control systems that allow custom defined $Keywords$ ?

Question

I was wondering if there are any source control systems that allow administrators to define custom keywords which are replaced on check in with different behaviours (i.e. similar to $Id$ or $Author$ etc.)

I'm only familiar with SVN and CVS which have a set list of keywords, but there would be applications for something like $LineNo$ or $MyLicenceText$. I'm sure there would be other use cases. The idea would be to create a plugin architecture where the behaviour of a keyword could be defined or modified.

So my question is - is there a tool (commerical or open source) that already has something like that?

Edit: Doing it as a part of the build is a valid way of solving the problem, however would cause issues if a developer did not do a build prior to check-in. Imagine for something like $LineNo$, if the build was not in sync with the source exactly, the value could easily be incorrect. For keywords with more static behaviour though (like $MyLicenceText$) replacement on build is a valid solution.

Answer 1

You could look at the filter attribute that you can set with a .gitattributes file in Git. This lets you define two transformations, known as smudge and clean, which let you transform a file in any arbitrary way when you check it out and transform it back again when you check it in.

Answer 2

Like Brian above said for Git, Subversion would also let you do pre/post commit hooks that could do substitution for $Keywords of this form$. I think the problem in the SVN world is that you really should not modify the files.

Here's what the SVN book warns:

While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be tempting to use hook scripts to automatically correct errors or shortcomings or policy violations present in the files being committed, doing so can cause problems. Subversion keeps client-side caches of certain bits of repository data, and if you change a commit transaction in this way, those caches become indetectably stale. This inconsistency can lead to surprising and unexpected behavior. Instead of modifying the transaction, you should simply validate the transaction in the pre-commit hook and reject the commit if it does not meet the desired requirements. As a bonus, your users will learn the value of careful, compliance-minded work habits.

Is there any reason you can't do this during the build process with Ant or Maven?

Answer 3

Why don't you use a trigger? Wouldn't it work?

Something like pre-checkout (or pre-update, depending on the jargon) and pre-checkin?