Greg Stein <gstein_at_gmail.com> writes:
> 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.
The Ev2 add_file/add_directory functions both have a replaces_rev
parameter so although Ev2 no longer sends "delete before add" explicitly
it is still treating replace differently from simple add. The client is
going to use that information to do "delete before add" itself.
So how do we handle case-insensitive clients? I see two choices: either
we add ordering to the server or we require the client to accumulate all
adds/deletes before acting on any of them.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-05-01 11:29:07 CEST