Re: svn commit: rev 7541 - in trunk/subversion: include libsvn_client libsvn_wc

[[ taking this Cc: to the list -- there might be useful info here ]]

Greg Stein <gstein@lyra.org> writes:

> I'm not sure how sarcastic you're being here. Is there a problem or
> not?

No sarcasm in this mail at all. Well, I guess that "I, uh, ..." might
read like that -- if that's what threw you, sorry 'bout that.

The difference between doing checkouts the old way, a flat "gimme a
directory and everything down in it", to this new "make an incomplete
dir and update it" is that in the former, we explicitly asked for the
checkout root dir and all its properties, which meant we got the UUID
and entry props for that directory.[1] Now, we claim to already have
the directory, though without *real* node props and without any
children. The result is that dir-delta sez, "Oh, excellent! That's
data I don't have to send to you, then. I'll only send you the
missing node props[2] (if any) and the missing children (if any)."

In the case of a checkout of revision 0, dir-delta sez, "Well, shoot,
all there *is* in revision 0 is an empty root dir with no node props,
and hey, you have an empty root dir with no node props! NOOP."

Now, we could make dir-delta go through the extra work anyway. "Oh,
you have an empty root dir and you need an empty root dir? Well, how
about I open your empty root dir, send you some 'entry props' you may
or may not already have, and then close your dir." This gets us our
properties, but now we're making the delta driver lie about the delta,
which means that all the driven editors that care need to grow logic
to know the difference between open-root/change-dir-props/close-dir
where there really is a delta versus when it was only driven that way
because of our little white lie.

Now, admittedly, even the current truthfulness of dir-delta has
required several editors to grow extra logic. You'll see the
edit_baton->root_opened boolean in many places, used in close_edit()
calls to remember that there was no delta at all. For some editors,
this might trigger functionality that's identical to an
open_root/close_dir drive. For others, this is not the case.

I dunno the right answer to this theoretical problem. The
'entry_props' boolean and behavior in svn_repos_dir_delta() feels
yucky to me, but without it, we'd need to grow some out-of-editor-band
way to transmit data in all the RA layers (seems quite a bit more
yucky). A solution could be for libsvn_repos() to grow a wrapper
editor who job is solely to append entry props to the normal edit
stream, but it would be used in exactly every place that the
entry_props attribute was set, so that would probably only complicate
things. On the flip side, it could also, where its own
eb->root_opened was false, forcibly do an
open_root/change_dir_props(entry_props)/close_dir on its wrapped
editor. The result would be a much more theoretically pure
svn_repos_dir_delta(), though.

Further complicating matters is that svn_repos_finish_report()
*always* calls svn_repos_dir_delta() with the entry_props flag set to
TRUE -- which means that non-WC-modifying operations like 'diff' and
'status' get these things even though they do nothing but immediately
filter them out with svn_wc_is_normal_prop() or with property
categorization.

--
[1] The kludginess of treating a repository identifier as a path
    property is left as extra credit for anyone with time to solve
    it.  And I might bear as much guilt as anyone else for this -- I
    don't recall the history.
[2] Bear in mind that "entry props" are not "node props" -- they are
    kludgily transmitted by dir-delta when a) the entry_props flag is
    set, and b) when dir-delta would already otherwise be transmitting
    a delta.
> > > > * subversion/libsvn_client/checkout.c
> > > >   (svn_client__checkout_internal): Fetch the repository UUID, and
> > > >     update calls to svn_wc_ensure_adm(), passing that UUID.
> > > 
> > > I'm not familiar enough with the underlying code/control/data flow here,
> > > but is this special-casing the UUID too much? Are we going to miss out on
> > > other (entry) or revision properties?
> > 
> > Yes.  Shoot.  I, uh, forgot about that when I made this change.
> > 
> > I suppose we could go back to making dir_delta call open_root() no
> > matter what, oh, and then call change_dir_prop() even though no props
> > were changed.  Which means we have to teach every editor to know the
> > difference between a real delta and a fake one.
> > 
> > > This is adding yet *another* turnaround to the server, isn't it?
> > 
> > Yes (unless the UUID is cached in the session baton, which is highly
> > unlikely).
> > 
> > I'll gladly revert, and I'm all ears for better suggestions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org