← Back to branch summary

~ubuntu-branches/ubuntu/trusty/subversion/trusty-proposed

« back to all changes in this revision

Viewing changes to notes/autoversion-compatibility.txt

  • Committer: Package Import Robot
  • Author(s): Andy Whitcroft
  • Date: 2012-06-21 15:36:36 UTC
  • mfrom: (0.4.13 sid)
  • Revision ID: package-import@ubuntu.com-20120621153636-amqqmuidgwgxz1ly
Tags: 1.7.5-1ubuntu1
* Merge from Debian unstable.  Remaining changes:
  - Create pot file on build.
  - Build a python-subversion-dbg package.
  - Build-depend on python-dbg.
  - Build-depend on default-jre-headless/-jdk.
  - Do not apply java-build patch.
  - debian/rules: Manually create the doxygen output directory, otherwise
    we get weird build failures when running parallel builds.

Show diffs side-by-side

added added

removed removed

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