Re: editor v2 and replace

Karl Fogel wrote:
> 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?

Admittedly, that's a little shaky. I think we should write a comment like this:

* A replace should be represented by a call to add(..., is_replace=TRUE)
* instead of a delete() followed by an add(). If you want to use the
* non-atomic way (a delete() followed by an add()), first consider it
* carefully and discuss with the Community. If it is accepted, it should
* be clearly marked as not using the standard way of operating the editor.

Also, I think the cases where the driver wants to send separate calls don't
worry that much about atomicity by definition. ...at least that's how it
*should* be :)

>
> 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.)

My 'atomic' is a little lower level. I'm currently worrying about how to
invoke the callbacks, not whether the resulting replace operations are
really being carried out atomically, yet. But this sounds good.

I've just seen incredibly spread out code in the callbacks implementations
that should actually just be a couple of consecutive lines. These might be
caching an awful lot of delete operations... it's Not Good.

Thanks a lot for your feedback :)
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2362454