Greg Hudson wrote:
> In my vision, $UpdateRev$ reflects the .svn/entries state of the file it
> lives in, and is only re-expanded when the entry is changed. This can
> be implemented efficiently, as long as we record enough state in the
> entry to avoid re-expanding a file when its svn:keywords property does
> not contain UpdateRev. Also, a very similar mechanism can update $URL$
> after an "svn switch", fixing #1975.
I'm still not sure I see where the /value/ to substitute is coming from.
svn_client_status2 (which is really all svnversion calls) collects the
rev number(s) by walking the entire WC and examining the entries file.
A normal update _does_ walk the WC, but it does so recursively and does
not keep track of the max/min rev numbers seen (as status2 does). I
don't see a way in the current architecture to have a value to
substitute without performing a full WC scan first.
Plus, this would still require the file-to-be-updated to have be changed
(if only by changing the timestamp), which was not (AFAICT) what Molle
was describing. /I think/ what was being described originally was
something more like your second example, where specific files would be
updated/re-expanded every time 'svn update' was executed. I'd like
Molle to clear this up, since only the OP can explain what was being
expected with this feature.
> In a different vision, $UpdateRev$ reflects the version state of the
> entire working copy no matter how the working copy is modified.
> foofile" command, or it would involve storing, in each directory's .svn
> area, a list of files whose svn:keywords property contains UpdateRev.
That latter methodology is probably unnecessary. We already have a list
of what keywords a file contains (the files in .svn/props directory).
What we don't have at a convenient point is which files have the
keywords we are interested in. If the .svn/entries file contained a
'dirty-keyword' entry, it would be straightforward to recursively walk
the tree and look at the entries file for any file that needed
re-expansion that wouldn't otherwise be considered for update.
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Lanham, MD 20706
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Oct 11 19:52:50 2005