[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: help me show others that there are valid reasons for not supporting a $log$ keyword!

From: Alec Kloss <alec.kloss_at_oracle.com>
Date: Tue, 16 Sep 2008 08:51:42 -0500

On 2008-09-16 09:32, Steve Povilaitis wrote:
> What else folks?

Well, any argument against any of the svn:keywords works for log
too. $log$ is just worse than the other substitutions.

> Also, for every tagged release we do for the customer they're going to want
> an export of the source with the revision log for each file appended to the
> beginning of the file. Have any of you had to do something along those lines
> and would you mind sharing how you accomplished it?

I think it's common to try to use substitution keywords in the
source control system to handle release engineering problems
like this. The releng I take care of stamps the current revision
number of the repository and other interesting facts into the
source files prior to compiling them and then stamps the object
files with a SHA-1 digest of their content for tamper/error
detection. There's no reason I couldn't stick an entire svn log
into the source files prior to building them. Assuming your
sources are archived permanently for a release build, I don't
really see anything wrong with stamping the log into them. If
disaster strikes and your repository is irreparibly destroyed,
your archived release sources have some extra information in them.

Of course, it'd be smarter to just archive your whole repository at
release time and put it in the safe place where your archived
sources would go instead. If you're truly worried about the end
times, keep a copy of your compilers, subversion itself, and your
releng OS in the same super-safe place. That's my $0.02.

Alec.Kloss_at_oracle.com			Oracle Middleware
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x432B9956

  • application/pgp-signature attachment: stored
Received on 2008-09-16 15:52:08 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.