- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 25 Apr 2002 23:00:30 -0400
- To: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
If the client first does a MOVE, then I agree there's not much an auto-versioning server could reasonably do. Just for interests sake, what is the motivation for those libraries to do a <MOVE-to-temp1, PUT-to-temp2, MOVE-to-real, DELETE-temp1> instead of the simpler <PUT-to-temp, MOVE-temp-to-actual> ? Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Am Mittwoch den, 24. April 2002, um 14:49, schrieb Clemm, Geoff: > One workaround that comes to mind is to interpret a MOVE from a > non-version-controlled resource to a checked-out VCR as a COPY/DELETE. First the good news: if you have a shell on OSX and do a cp test.txt to /Volumes/dav/test.txt where "dav" is a WebDAV mounted volumes, the webdav code in OSX does basically a LOCK/PUT/UNLOCK on an existing test.txt. So (auto)versioning will do the job. However if you use the Finder or any Carbon/Cocoa Application, some library code will do (on save in the GUI): 1) MOVE /Volumes/dav/test.txt /Volumes/dav/test~.txt 2) PUT /Volumes/dav/data1234.txt 3) MOVE /Volumes/dav/data1234.txt /Volumes/dav/test.txt 4) DELETE /Volumes/dav/test~.txt (modulo LOCK/UNLOCK) I see no chance to keep any versioning on text.txt. //Stefan > Unless someone comes up with a better idea, I'll add this to the 3253 > "errata" sheet as an interoperability suggestion for the MOVE request. > > Cheers, > Geoff > > > From: Kasia Jonca [mailto:Kasia.Jonca@merant.com] > > We've been testing Merant versioning WebDAV server with Windows XP > "redirector" and Mac OS X WebDAVFS. The behavior of our versioning > WebDAV server is equivalent to the behavior of the DeltaV server > with auto versioning. On the surface things seems to be working > but if you look closer the situation is really bad. Both clients > behave like a file system and perform what is called a "safe > save". This means that the new changes are saved in a temporary > file on the WebDAV server, the old file is deleted and then the > temp file is renamed. This means that when a file is being saved we > lose the previous versions, a new version history is created. Both > clients also create a few versions that seem to contain some > temporary values making the version history unacceptably polluted. > We are quite concerned since both Windows XP "redirector" and Mac > OS WebDAVFS would enable access to WebDAV server from any > application on those platforms. With this behavior the only > solution for us or a DeltaV server would be to deny the write > access to these agents so that the user data is not destroyed and > polluted. This is quite a change from our expectations on what > DeltaV would do for us and we are hoping that some solutions can be > still found. Did anybody test these clients with a DeltaV server > implementation? Any comments, suggestions, explanations? >
Received on Thursday, 25 April 2002 23:01:06 UTC