Jack Repenning wrote:
> At 2:16 PM +0100 9/8/03, Julian Foad wrote:
>> (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
> Hmmm ... that depth would have to be user-settable, right? So either
> the keyword includes the target to use
> $SvnRevision:../../..:$ non-expanded
> $SvnRevision:../../..:6329-9654$ expanded
> or maybe the svn:keywords value that specifies to expand this one would
> also name the target
> $SvnRevision: 6329-9654$
> svn pset svn:keywords SvnRevision:../../.. thatfile
> Something along those lines?
Yes, something along those lines.
>> 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.
> I'm not sure it makes sense to me. More to the point, does it make
> sense to the people who want this?
> Suppose the file with the expandable keyword is "conf/revfile" (below
> trunk/ or tags/whatever/ or branches/whatever/, as the case may be). To
> build a release that includes one patch, the buildmeister does:
> cd trunk/ # or branches/whatever, or ....
> svn up -r 1234 # includes conf/revfile, so it gets 1234
> svn up -r 2345 src # excludes conf/revfile, so it doesn't change?
> Now revfile says "1234", but svnversion on "." would say "1234:2345",
> which I think is not what anyone would want.
That is just the same as if you had a manually maintained "VERSION.TXT" file in the root of the project, and updated only a sub-tree. VERSION.TXT would be out of date. If you put VERSION.TXT in the sub-tree, then it would have been updated ... regardless of whether it was manually maintained or using this new keyword. The system works exactly as designed and as expected. I think that is reasonable behaviour.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Sep 8 21:12:15 2003