On Tue, Mar 19, 2002 at 07:08:30PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > Of course, this *does* mean we have to accept the reality of buffering all
> > of that data in memory, in the client.
>
> Buffering a list of names is okay, imho. Just not the contents. :-)
>
> (Yes, someday there will be a directory with ten billion changed
> files. I'm sure we'll get a patch when that happens. :-) )
That's my fear :-)
> > (*) ra_dav had the server tell it what was actually changed in the commit,
> > which meant that the client didn't have to record it. however, the
> > server included bubbled-up directories in its change list. if we omitted
> > the bubble-up changes from the server's response, then we could remove
> > the tracking in ra_dav. this latter algorithm is my favored approach.
>
> We ignore them anyway, right?
Actually, it appears that we still use the returned list. If a returned item
is in the hash, then it gets bumped. Otherwise, we look in the hash for a
parent of the returned item, which has a 'recursion' flag set on it.
Oh... and wait a second. We also tweak some WC props in there. Thus, ra_dav
is still going to need access to the list of committed targets, and it will
still be doing some work. If the commit driver wants to do the bump *after*
the close_edit() returns, then things should be fine (and we can remove the
call to the bump_func from ra_dav).
I'd still prefer if the server just returned non-bubble directories and we
drove the bump/wcprop stuff from that, rather than keeping a big, mother
list in memory. But hey, if the client is going to generate it in the first
place to deal with disjoint WCs, then the RA layers definitely shouldn't be
building a duplicate.
(it just needs to be determined whether they truly are duplicates; if not,
then what differences can be ironed out to bring them into alignment)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 20 02:35:44 2002