Re: editor v2 and replace

Karl Fogel wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>> Hmm. I figured that with the "add follows" flag, then you could know
>> to avoid dual-notifications, and just wait for the add. But yah...
>> then you'd need to remember (at add time) that a delete had happened.
>> More cross-call state.
>>
>> Adding a flag to the add calls should work. Tho I hate the "replace"
>> terminology. Maybe "overwrite=TRUE" is better? (and, of course,
>> failure if you're trying to overwrite, and nothing is there)
>>
>> Bikeshed. But yah. Extending the add calls sounds better. Thanks!
>
> I know I'm sort of chiming in from the late Jurassic here, but:
>
> While +1 on 'replace' as a single operation in editor v2, I think it's
> important that the editor call sequence match up the working-copy
> metadata. In other words, if someone replaces 'foo' with 'bar' in their
> working copy...
>
> $ svn rm foo
> $ svn mv bar foo
>
> ...then the working copy (v2) metadata should clearly indicate on both
> sides that it's a replacement, and when the editor call happens, it
> should record (also on both sides) that the local state has now been
> "satisfied" by the editor.
>
> This could be a little tricky, because you don't know which side you'll
> encounter first in a commit or update crawl. I guess what I'm saying
> is, encountering either side should be like encountering both, as far as
> the working copy is concerned: the single editor call should update both
> sides.
>
> Is that too hand-wavy to be meaningful? Do you see what I'm getting at?
> (Or is this already taken for granted?)

Hi Karl,

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.

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.

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

Is that Go? :)
~Neels

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