At 4:13 PM +0100 9/5/03, Peter Childs wrote:
>On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
>
>> you might use the svnversion command to do this:
>>
>> compile using gcc -DVERSION=`svnversion .`
>>
>> There currently is no keyword which is substituted with the output from
>> svnversion.
>
> Super a keyword might be useful one day however.... maybe a TODO
>is in order.
Certainly, this idea is getting common enough to deserve a FAQ entry
(with e.huelsmann's workaround, very likely).
It seems to me (to many of us) that treating this info as a keyword
creates more problems than it solves. I wonder, if you don't mind,
if you could explain a bit more of why you want this, and why you're
not concerned about the problems it engenders?
Here's a partial list of those problems:
* any file containing this keyword would have to be changed (by SVN)
every time you update, even if the file itself had not changed.
* The indication is ambiguous, since a given revision number actually
applies to many complete project versions, in trunk/, tags/*/, and
branches/*/.
* Updates of anything other than the whole working copy/build tree at
once make this very weird--if you update some subdirectory that does
*not* contain this file, ought this file also to be updated?
* And commits present that same problem in an even worse way, since
committing a change by definition advances the repository revision,
and yet does not give you the changes to all the files you're not
committing.
To thread that all into a coherent story, suppose your project has
been under development and maintenance for some time, and you have
project/trunk/* the active working stuff
project/tags/REL1/* the stuff you sent to customers as release 1
project/branches/REL2/* the Release 2 stuff, nearing release and
branched for stabilization
project/branches/patches/REL1.1.* new work to fix a bug just found in REL1
Now when the maintenance engineer commits a change to
REL1.1/src/foo.c, that bumps the revision number for the whole
repository. But it has nothing to do with the other areas. If the
release engineeer building the branches/REL2/* nightly builds runs
"svn up", then things get incremented and rebuilt, even though no
changes have happened to the REL2 sources--quite the opposite of what
you want during "stabilization!"
For such reasons, it seems to us that this annotation *belongs* in
the build system (as suggested by e.huelsmann), where local needs,
assumptions, practices, and policies are known, and the annotation
mechanics can be tweaked accordingly.
In a similar vein: is there some existing VC system that does
something like this for you? I'm not familiar with that. If so,
maybe a description of how it manages this, and how you use it, would
help us understand. Maybe this idea comes from some fundamentally
different development model than I used above? For example, I could
see it a bit more in the "thousand points of light" repository galaxy
model of BitKeeper and Arch, where you would more or less expect the
repository revision to reflect only your own local fragment of the
whole.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Sep 6 20:16:50 2003