[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tracing and tracking commits in the new system.

From: <cmpilato_at_collab.net>
Date: 2002-03-21 18:00:40 CET

Greg Stein <gstein@lyra.org> writes:

> 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).

Is this really true? I mean, if you put aside the revision bumping
stuff, is it harmful for ra_dav to tweak those WC props for items that
were returned by the server but not in the committed items list? If
those extra tweaks are non-fatal (or perhaps just inefficient), then
ra_dav doesn't truly need the list of committed items.

> 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.

Right. But the server should still not return bubble-up directories,
don't you think?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 21 18:01:51 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.