- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 24 Apr 2002 08:49:02 -0400
- To: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
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. 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 Wednesday, 24 April 2002 08:49:40 UTC