Re: Current Updated Revision Number
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-09-08 15:16:02 CEST
Jack Repenning wrote:
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)
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
Solved: applies to a specific sub-tree.
> * Updates of anything other than the whole working copy/build tree at
Solved: mixed-revision WC gives mixed-revision output string.
> * And commits present that same problem in an even worse way, since
Solved: this is a mixed-revision WC.
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.
This is an archived mail posted to the Subversion Users mailing list.