Greg Stein <gstein@lyra.org> writes:
> > All this change does is to implement the same merging logic that has
> > been in tree.c:merge() all along. Remember, we're merging into HEAD
> > here -- if the request is to delete entry E, and it turns out that
> > entry E is already gone,
>
> What if E *never* existed?
>
> IMO, I'd call that an error which should be trapped.
That case is impossible, because the user *has* a resource E locally,
and her records indicate E was versioned in this directory at some
point in the past (and the directory's existence on the server *is*
checked). For her to attempt to delete it on the repository now and
discover it's already gone just means the work she wanted to do is
already done.
Now, I'll grant you that someone could tweak their wc, or manually
send deletion commands over the network, or whatever, to attempt to
delete something that never existed at that path. So what? It's not
important to answer spoofs. :-) Note that the user's records have been
verified as accurate right up to the parent directory of E, so it's
not like this method will fail to detect a mismatch between wc and
repos.
> But simply throwing out an error doesn't have the case of "never existed".
> When I meant "deleted originally", I meant the initial request-to-delete of
> something that just doesn't exist. (as opposed to a second deletion of
> something which existed but had been deleted before)
Then the repository should detect if the thing ever existed here in
the past (which it is perfectly capable of doing).
> So... maybe we have some issues distinguishing the two cases, and more
> getting them reported back to the client. But tossing the error doesn't seem
> like the right solution.
The question here is whether or not it *is* an error. :-) If we
determine it isn't, then tossing it is the right solution, although
"tossing the error" might be a hair-raising buzzword designed to cause
riots in the streets of San Jose. :-)
Anyway, as we all just agreed on IRC, we'll do this by ignoring
ra_dav's 404 on the deletion, and everyone's happy .
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:45 2006