Thomas Broyer wrote: > > Luke Arno wrote: > >>On 11/6/05, Eric Scheid <[EMAIL PROTECTED]> wrote: >> >>>Also, from the users p.o.v., when reviewing a collection of recent >>>changes and seeing some minor foobar that needs fixing, and doing >>>the effort to fix those changes (including looking up the proper >>>spelling, searching for an alternative URL for a broken link, etc etc), >>>only to later find out that not only did someone else already do those >>>fixes, but did them before I even synced, that would make me want to do >>>violent things against whoever thought a leaky sync is sufficient and >>>not a problem. >>> >> >>Boy, that was a bad move on you or your client's >>part. You should have done a GET (click "Edit" >>button or whatever) before you went to all that >>trouble. What a waste. >> >>If I change a bunch of code that I checked out a >>week ago and don't do an update first, only to >>find out that someone else made those changes >>3 days ago, that would be my fault. I wouldn't >>blame it on CVS. > > > If I "Atom update" to sync with the AtomPP server, I expect to have the > latest version of the entries. > If I go offline before editing the entry (therefore not doing a GET before > editing), I'll end up editing something not up-to-date. When "commiting", > if someone had made the same changes and I happen to know he did it even > before I "Atom updated" my local store; it wouldn't be my fault and I'd > sure say "who the hell made such a bullshit protocol !!!"
The CVS thing is not a useful comparision. Version control systems are much more powerful than APP. You have to go to some effort to trash a CVS/SVN repository precisely because you have to run upd and even then you'll get a warning if you try to checkin against a stale working copy. It appears to be trivially easy to trash content with an Atom Store using APP. As I said elsewhere, go and see how svn works over WebDAV to see how this problem is solved in the web context. I think we need to step back and ask whether synchronization via updates plus server errors where there is conflict is core to APP before having these kind of side threads. cheers Bill
