Re: Current Updated Revision Number

Jack Repenning wrote:
> 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.

Depends on whether "this info" is:

(a) the latest revision of the repository. Yes. All the problems you described apply.

(b) the WC base revision, as given by "svnversion". A keyword based on "svnversion", with its argument restricted to parent (grandparent, ...) directory of the file in which it appears, solves most 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.

At first I thought the problem was that the file ought to be updated even when it is not in the (implicit or explicit) list of files to be updated. But that is not a problem: the file will always be in the list during a recursive update of any of its parents, and in non-recursive update that does not include this file, it will not be updated. That makes sense.

The problem is that the file(s) with the keyword cannot be correctly updated until all of the other files have been updated, or at least until their new revision number is known. This makes the implementation awkward, especially in the case of a partial (aborted) update.

> * The indication is ambiguous, since a given revision number actually
> applies to many complete project versions, in trunk/, tags/*/, and
> branches/*/.

Solved: applies to a specific sub-tree.

> * 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?

Solved: mixed-revision WC gives mixed-revision output string.

> * 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.

Solved: this is a mixed-revision WC.

...
> 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.

I'm half in agreement, as the semantics of an "svnversion" keyword don't fit as cleanly as the other keywords, but many uses of Subversion don't include a build system. I suppose they could always be given one, e.g. a wrapper that runs "svn" and then "svnversion" and puts the output of "svnversion" into an appropriate file, but there are down sides to that (e.g. portability).

I would support the addition of a keyword based on "svnversion" semantics if people can come up with a reasonable implementation for it.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 8 15:16:06 2003