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.
> If we have to extend the editor interface, there's nothing we can do,
> but I would like to avoid clutttering it if possible.
>
We don't _have_ to extend it, of course, because each client operation
can re-implement the necessary logic. It's just more convenient for
those callers if we do.
I'm not wedded to the interface I proposed either - I'm more interested in
whether the concept makes sense. For example, we could just add a single
new delete_directory call that works like a parallel to add_directory,
except that it can only contain other delete_directory, close_directory,
and delete_entry calls (rather than add_directory/add_file):
open_directory A
delete_directory B
delete_entry x
close_directory B
close_directory A
Just to make one thing clear: I'm not proposing to change the editor
interface before the atomic-renames work does, which I guess makes this
something for 1.5.
> On a side note, you can't do delete_entry after having opened a
> directory
> according to restriction 1. of the editor interface documentation, so
> we need something new here.
>
Yeah, that's why I said 'the spirit' of the interface. But let's no go
into that, it's not something I'm seriously proposing.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 24 10:28:11 2006