[Cialug] Subversion 1.4.3

[Nathan Stien]

On 5/22/07, carl-olsen at mchsi.com <carl-olsen at mchsi.com> wrote:
> I seem to have Subversion working well now.

That's great!  It's a lifesaver of a tool.

Here's a tip you didn't even ask for.  A feature I particularly like
to use is svn:keywords.  It lets you have keyword replacements like
$Id$ from the bad old days of CVS.

You do something like this:

    svn propset svn:keywords 'Id Revision LastChangedDate' *.c *.h

And then when you have $Revision$ or any other supported keyword
somewhere in your source text, it gets replaced with relevant info
whenever you commit a file.   I tend to have a header block in each
file that looks something like this:

/*********************************************************************
* FILE: main.c
* PROJECT: <snip>
* PURPOSE: initialization, main program loop
* AUTHOR: Nathan Stien <nathanism at gmail.com>
* SUPPORTED PLATFORMS: lpc210{1,2,3}
* $LastChangedDate: 2007-02-20 20:08:23 -0600 (Tue, 20 Feb 2007) $
* $Revision: 675 $
*********************************************************************/

That way, even if the file escapes my repository and someone else
finds a problem, I can pinpoint exactly where/when in my repository
their version came from.  And no more out-of-date last-changed-dates,
which was always a big problem for me.

You can also do tricks like putting "$Revision$" inside a string
literal which your program can parse and use for an about box or
--version response.  But beware, the keywords are only updated in a
given file when you commit changes to it, so an unchanged file in your
project will have a lower $Revision$ number and $LastChangedDate$.

When doing revision diffs and such, subversion un-expands the keyword
substitutions before comparing with the repository so you don't get
spurious differences.

Here's some real docs:
    http://svnbook.red-bean.com/en/1.0/ch07s02.html

I also really like bzr for a lot of versioning tasks, but they seem to
have philosophical objections to the versioning tool modifying the
versioned file for this type of keyword replacement.  There was a row
on their mailing list about it last year or so, and now they seem to
half-heartedly want to support it, but we'll see.  In the meantime
someone wrote a plugin which you can run during your build step to
generate a .h / .py / whatever containing a native data structure
describing *project-wide* revision information, so that's probably
more useful for the about box case.

OK, gonna stop rambling now.  I have a strangely intense fondness for
software engineering tools, and it's hard to stop gushing sometimes.
:-)

-- 
Nathan P. Stien
Consulting Engineer / Software Developer
Embedded Systems Electronics and Software
http://linkedin.com/in/nathanstien
Mobile: 309.241.2581