sussman@collab.net wrote:
>
> I hope that's not what he's saying. Philip seems to be describing
> what you already described in your first mail: when the client sends
> the update report, it describes the schedule-delete directory as
> "missing", so it's removed from the repos txn. And thus the server
> never sends a tree delta at all, which leads to problems.
i'm confused by the terminology here. the dir in question has been
'rm -rf'ed, but has not (in the working copy) been scheduled for
deletion. so when you say 'schedule-delete', do you mean that it is
due to be deleted by the update, or were you confused about the use case?
> Perhaps schedule-delete directories shouldn't be described as missing
> at all -- only "deleted" ones. That would make the server send a
i'm confused again. what do you mean by "schedule-delete" and
"deleted", respectively?
> deletion command, which the client would then carry out, even in the
> presence of a schedule-delete: it could be considered a case of
> "merging" tree changes from the server which don't conflict.
you probably understand this better than i do, but just to make sure
we're on the same page:
in the present use case, directory "foo" is missing in the working copy.
whatever we do, it has to do the right thing in the case where "foo" is
(1) present in the target revision
(2) absent in the target revision
but AFAICT, at the level at which we're calling reporter->delete_path,
we don't know which of those cases we're dealing with (we only know the
state of the working copy, not the state of the target revision in the
repos.)
what we need is for the server to send a deletion command in case (2),
which would seem to require that we *not* call reporter->delete_path;
however, case (1) would seem to require that we *do* call
reporter->delete_path in case (c).
assuming that we're on the same page so far, i'm probably just slow
catching on -- could you spell out your idea a bit more for me?
thanks,
brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 21 18:57:05 2003