1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Here's the status of how well SVNAutoversioning works against various
DAV clients. Feel free to update this as we learn more.
First, a general note: the one big feature we're lacking is support
for the LOCK and UNLOCK dav requests. This pretty much means that you
won't be able to open a file (in write mode) directly from the dav
share; every client tries to LOCK in that case. [Note: mod_dav_lock
in httpd-2.1 addresses this.]
The workaround, for now, is to copy (or drag) the file out of the
share, edit it, then copy (or drag) it back.
The basic set of tests
======================
1. Add new file (PUT)
2. Add new folder (MKCOL)
3. Rename a file (MOVE)
4. Rename a folder (MOVE)
5. Copy a file (COPY)
6. Copy a folder (COPY)
7. Delete a file (DELETE)
8. Delete a folder (DELETE)
9. Open remote file directly (LOCK)
10. Copy/drag remote file to local disk (GET)
11. Copy/drag local file back on top of remote file.
(PUT, or DELETE/PUT, or LOCK, PUT, UNLOCK)
Nautilus 2.X (tested by sussman and ttimo)
============
1. Add new file (PUT)
Check: but it does two PUTS instead of one. First it PUTs an
empty file, then PUTs data into it. So we get two new revisions.
2. Add new folder (MKCOL)
Check.
3. Rename a file (MOVE)
Check.
4. Rename a folder (MOVE)
Check.
5. Copy a file (COPY)
Can't figure out how to make Nautilus issue a COPY command. If I
control-drag to copy, or if I right-click to copy/paste, it still
ends up doing two PUTs, just like in test #1.
6. Copy a folder (COPY)
If I right-click to copy/paste, it creates *N* new revisions: one
MKCOL, followed by two PUTs per file, ugh.
7. Delete a file (DELETE)
Check.
8. Delete a folder (DELETE)
Ugh. It creates N new revisions by issuing a separate DELETE
request for every item in the subtree, then finishing with a DELETE
on the dir itself. Isn't just the final DELETE needed? We should
send a patch to Nautilus.
9. Open remote file directly (LOCK)
Opens file as read-only, but it never tries to just GET. I wonder
if this dav implementation is simply feature-incomplete. Maybe it
just opens files as read-only no matter what...?
10. Copy/drag remote file to local disk (GET)
Check.
11. Copy/drag local file back on top of remote file.
(PUT, or DELETE/PUT, or LOCK, PUT, UNLOCK)
DELETEs old file, PUTs twice. Yucky.
Win32 WebFolders (on Win2K-sp3) (tested by sussman)
================
This works pretty well: the details needs to be filled in below.
1. Add new file (PUT)
2. Add new folder (MKCOL)
3. Rename a file (MOVE)
4. Rename a folder (MOVE)
5. Copy a file (COPY)
6. Copy a folder (COPY)
7. Delete a file (DELETE)
8. Delete a folder (DELETE)
9. Open remote file directly (LOCK)
LOCK is not supported by WebFolders.
10. Copy/drag remote file to local disk (GET)
11. Copy/drag local file back on top of remote file.
(PUT, or DELETE/PUT, or LOCK, PUT, UNLOCK)
OS X (fitz/thom/sabi/sussman/jerenkrantz)
====
OS X's DAV client requires LOCK to do write operations.
httpd-2.1 HEAD now has mod_dav_lock. When used with DavGenericLockDB
(part of mod_dav_lock), all operations work as follows:
1. Add new file (PUT) - Works.
2. Add new folder (MKCOL) - Works.
3. Rename a file (MOVE) - Works.
4. Rename a folder (MOVE) - Works.
5. Copy a file (COPY) - Works.
6. Copy a folder (COPY) - Works.
7. Delete a file (DELETE) - Works.
8. Delete a folder (DELETE) - Works.
9. Open remote file directly (LOCK) - Works.
10. Copy/drag remote file to local disk (GET) - Works.
11. Copy/drag local file back on top of remote file. - Works.
(PUT, or DELETE/PUT, or LOCK, PUT, UNLOCK)
Note: The OS X DAV client isn't a speed demon.
Note: When using it as a file system and editing it directly (i.e. using
vi in the share), the client will PUT the new file as a temporary location,
DELETE the old file, MOVE the temp resource to the original file name. This
probably isn't optimal on Apple's part. It does wonders for the file
history.
Note: It seems to try to create ._<file> as well. Implications of this
are not yet understood (fitz hinted at AppleDouble as the reason).
Note: If you see a problem mounting the repository, you may need to enable
the default BrowserMatch directive in httpd-std.conf for WebDAVFS.
(It's included in the default httpd.conf now.)
Something like:
BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully
Linux davfs2 (hadaka)
============
Apparently this doesn't work at all. This client always attempts to
LOCK before any kind of write operation (PUT, PROPPATCH, etc.).
Talk about paranoid!
|
