On Thu, Oct 18, 2001 at 03:15:59PM -0500, firstname.lastname@example.org wrote:
> Greg Stein <email@example.com> writes:
> > > mod_dav_svn should be trapping and ignoring the "item already
> > > missing" error that it's getting from the filesystem. Why?
> > > Because mod_dav_svn is *merging* on the fly, and in the world of
> > > merging, deletion is an idempotent operation. (svn_fs_merge() has
> > > the same rule: if you need to delete something, and it's already
> > > gone, it just moves on.) This is a pretty easy fix, and I'm
> > > almost done with it.
> > I don't understand how this can be the correct fix. What if a DELETE is
> > attempted and the file *truly* isn't there? I see no way to distinguish
> > between "deleting *again*" and "deleting *originally*"
> That's because there *is* no difference. :-)
> Hmmm, not sure what two cases you're trying to distinguish here...
> 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.
> than that means the deletion was already done
> by someone else. No problem -- not an error, it just means that you
> attempting to delete the entry is not a conflict (as opposed to, say,
> trying to modify its text). This has always been part of the merge
> logic, see this empty `else' clause in tree.c:
> /* It's a double delete, so do nothing.
> ### kff todo: what about the rename case? */
One tree deleted something, and the other tree requested a delete of that
same thing. Sure... that is fine because the requested-to-delete was
deleting something that used to exist.
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)
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.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:45 2006