Greg Hudson <ghudson@MIT.EDU> writes:
> > * all replace_*() calls now take both base_rev and target_rev
> > arguments, and NO paths at all
> > * the add_*() calls now take a base_rev, target_rev, *and*
> > base_path args, so we can support copy history.
> Um, target_rev? What happened to
> http://subversion.tigris.org/subversion-dev/current/msg01190.html ?
Excellent question. :-)
It had to do with the xml output editor, of all things. The problem
was this: consider the places where the target revision should be
shown in the xml. The only two reasonable spots, as far as I can see,
(Of those two, the first seems more natural, but an argument can be
made for either one.)
However, if a set_target_revision(dir_baton) function is used to set
the target revision, how would the xml output editor get that
attribute out in time? It can't do it in the replace_dir() call, but
it also doesn't know whether or not set_target_rev() is going to be
Another way of looking at it: it turns out there *is* a semantic
difference between passing an target_rev argument vs calling a
With an argument, the editor knows at the time of calling replace_foo()
or add_foo() that the target revision is either some number, or an
But with a function, the editor has no way of knowing, at the time it
calls replace_foo() or add_foo(), whether or not the
set_target_revision() function *will be called* next.
So the replace_foo() and add_foo() functions can't output their
attributes in time, but nor is there any event guaranteed to come
later to flush those tags out. We could insist that
set_target_revision() always be called no matter what, so the xml
output editor can just wait until that call before printing the tag,
but if you have to call it all the time, that's really no different
from just making target_rev be an argument.
Received on Sat Oct 21 14:36:21 2006