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

Re: hint for improved keyword substitution

From: Mycroft Holmes <psion.s5_at_gmail.com>
Date: Wed, 19 Mar 2008 09:52:38 +0100

On 18 Mar 2008, at 20:34, John Peacock wrote:

> That's not going to be possible, because the keyword stuff is
> strictly line-oriented (by which I mean that it only reads and
> processes a single line at a time).
>

if this is a problem, I'll modify my proposal: let the $template$ be
slightly customizable.
for example instead of replacing "$REV$" with "$REV: nnnn $" I'd like
svn to replace "// REV$" with "nnnn // REV: nnnn$"
(note that the ": nnnn" part is necessary to match the leftmost
"nnnn" in a second pass)

this will do, because I can write

#define VERSION // REV$

and svn will change to

#define VERSION 1234 // REV: 1234$

> Perhaps you would like this instead?
>
> http://subversion.tigris.org/faq.html#version-value-in-source

no :)
because I want finer granularity: in my project, each source file has
its own version number, as an integer (not as a string).
at the moment the only way to get this is:

1) every file X.h starts with
#include "version/X.txt"

(note that this is bad practice, since every file must know its own
name...)

the companion text files (which are not versioned) just state:
#define SVN_REV nnnn

2) before building, preprocess every file and generate all the
companion files parsing 'svn info' ...

but this procedure is going to cause BIG problems, since code CHECKED
OUT will build, but code EXPORTED from the repo will not!
so I'm firmly convinced this is an issue for svn.
furthermore, I don't see any practical use for keyword substitution
AS IS, except cosmetic (?) reasons (don't tell me that $REV: nnnn$ is
pleasant :)

  • application/pkcs7-signature attachment: smime.p7s
Received on 2008-03-19 10:20:48 CET

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

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