On Tue, May 1, 2012 at 04:17, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>
>> On Apr 30, 2012 4:49 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
>>>
>>> Greg Stein <gstein_at_gmail.com> writes:
>>>
>>> > I don't think there is anything that says we will see deletes first,
>>> > followed by adds. It just "happens" to have done that so far. But my
>>> > recent work ended up changing that order. Boom.
>>>
>>> delta_dirs in libsvn_repos sends deletes before adds specifically for
>>> this, see r852690.
>>
>> Okay. Thanks for the pointer.
>>
>> Do you believe this is something that should be specified in the editor
>> interface contract?
>>
>> (I'm a little leery of doing so; it seems very special-cased)
>
> It's an old problem, we had similar discussions about v1:
>
> http://svn.haxx.se/dev/archive-2002-02/0003.shtml
>
> In v1 "replace" is "delete" then "add", the server implements this and
> the clients rely on it. When the client is case-insensitive that makes
> some adds into replacements even though the server doesn't identify them
> as such.
Ugh. I just worry about how to write that as an interface contract.
In r1332562, I tried to fix the problem with some custom ordering, but
it broke a bunch of other things. I may not have coded it properly,
but I'm also reading this as "the editor driver needs to take a LOT of
care to order its calls properly". And (IMO) that totally sucks. I was
hoping that Ev2 could be random-access and get rid of all the damned
ordering constraints that Ev1 imposed on us. If we need to step back
and impose some constraints... okay. Maybe the design/concept was just
too aggressive. But I hope that we can clearly state any constraints,
and make it easy to implement. If drivers have to jump through crazy
hoops to satisfy some edge constraint, then it seems we have more
design work to do.
I'd appreciate any thoughts you have on this.
Thanks,
-g
Received on 2012-05-01 10:48:27 CEST