Neels Janosch Hofmeyr <neels_at_elego.de> writes:
> as to the real-life consequences, I'm still mostly grey. Haven't dug a lot
> of code about this. But I've seen the cases where the current callbacks just
> don't work well. Let's philosophize:
>
> Currently, combining separate editor calls to detect a replace has to be
> implemented by each receiver that needs to know. Even if the driver has that
> information right there, it still *has* to call delete() first, then add().
>
> Adding an atomic replace to the editor callbacks puts the load of the
> combining work on the driver. That's also the intention.
That sounds good. Actually, it's a more succinct way of expressing what
I was trying to say.
> Actually, we don't necessarily force *every* driver to make a replace
> atomic. I could imagine that some "editor pipe" in the code just agrees to
> not use that replace flag and remain issuing delete() and add() separately.
> Then again, I can't currently imagine a case where that first driver in the
> line would not have the replace information ready to pick up.
So there will now be two ways to express the same action, via the
editor? That is, you can call replace(A, B), or you can call delete(A)
and then add(B), and the result should be exactly the same either way?
It's a little worrisome to have two paths to the same result, but I
don't think it's fatal... and see below about atomicity.
> If a callback receiver doesn't need the atomic replace, it will just call
> its own delete() callback before doing the usual add() (given that add()
> will receive an is_replace or similar flag).
Sure. Callback implementations are up to the callbacks, as long as they
satisfy the promises of the editor v2 interface.
Atomic replacement in the standard working copy is possible: you write
intermediate data in a certain way, such that if svn is interrupted at
any point before the replacement is completed, subsequent 'svn cleanup'
*either* restores to the pre-replace status quo or completes the
replacement.
So perhaps the difference between achieving a replacement by calling
replace() versus by calling delete()-then-add() could be that the former
promises atomicity? (Atomicity through 'svn cleanup' is permitted.)
> Is that Go? :)
Oh, I wasn't trying to stand in the way of anything :-). Just wanted to
voice a design concern on the working copy side, that's all.
-Karl
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361916
Received on 2009-06-14 08:46:48 CEST