On Tue, 2005-10-11 at 13:51 -0400, John Peacock wrote:
> Greg Hudson wrote:
> > In my vision, $UpdateRev$ reflects the .svn/entries state of the file it
> > lives in
> I'm still not sure I see where the /value/ to substitute is coming from.
>From the .svn/entries state of the file it lives in, as I said. It's
one number. No "max/min rev numbers" for the entire working copy.
Go to your svn working copy and look at .svn/entries. See the
"revision" field in the XML entries (for the directory itself and for
any files whose revision differs from the directory). That's the number
which would be substituted in for $UpdateRev$ in my vision. Note how
that number differs from the "commited-rev" field which is substituted
in for $LastChangedRevision$.
[Regarding the other, more complicated vision:]
> > 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.
Gah. I say "it would require a recursive walk of the tree, or it would
require storing all this information," and you respond "it's probably
not necessary to store all ths information, since we could just do a
recursive walk of the tree." Well, of course.
Doing a recursive walk of the tree in response to "svn update foofile"
is not acceptable performance; such a command should be fast even if
you're operating in a very large working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 20:09:21 2005