Malcolm Rowe writes:
> On Fri, Apr 21, 2006 at 09:07:15PM +0200, Peter N. Lundblad wrote:
> > Malcolm Rowe writes:
> > > The first is to pause whenever we see a delete_entry and separately
> > > traverse the deleted subtree. I've already added code for repos->WORKING
> > > diffs to do this (which is easy because we need to traverse the local wc),
> > > but it's fragile and doesn't work for repos-BASE or WORKING->repos diffs
> > > (where we'd need to contact the repository).
> > >
> > > Also note that if we did this for repos-repos diffs, we'd need to use at
> > > least three connections: one to receive the report request, a second to
> > > traverse the deleted subtrees, and a third to fetch the contents of files.
> > >
> >
> > Why couldn't you just "check out" the deleted directory in the source revision
> > interpreting adds as deletes. This wouldn't require a third session
> > and it would work with old servers.
>
> Yes, I see no reason why that wouldn't work either (good idea). However,
> the number of connections isn't the real problem (I probably shouldn't
> have mentioned it).
>
>
> The real question was whether getting the names of deleted entries
> within a deleted subtree (rather than just the subtree root itself)
> is uncommon enough that we should require clients to implement the
> recursion logic themselves.
Well, isn't "the recursion logic" just to issue a single RA request on
an auxliary session and be prepared for the response? I don't know
how common that need would be except for the diff case. A nice thing
about the "checkout" idea would be that it works transparently with
servers from 1.0 and forwards.
A related topic here is the roundtrip problem of diff and merge.
Currently, for diff/merge, for each reported change, we need to do a
request to get the source of the delta, wait for that, and then
compare the source and target. Since this can't be pipelined, it
results in lots of waiting on the network layer.
Maybe, but this is an idea that just popped up in my mind, we could
introduce another editor into the mix. That editor would get the
relevant parts of the delta source "in paralell" with the main
edit. So, when we got an open_file with a text delta in the main edit,
we got the same operation, but with a fulltext for the delta source in
this new editor. When we got a delete_entry in the main editor, we
would get an add for the same entry (and its children) in the new
editor to describe the deleted target. If this is feasable (and I
don't know yet), this could solve both problems without hacking things
into the editor interface. I guess this idea has to live in our minds
for a while, so don't consider this a proposal:-)
Thoughts?
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 24 13:42:07 2006