On Tue, May 1, 2012 at 04:17, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: > >> On Apr 30, 2012 4:49 AM, "Philip Martin" <philip.mar...@wandisco.com> wrote: >>> >>> Greg Stein <gst...@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
