1 | NOTES ON VERSION COMPATIBILITY |
---|
2 | |
---|
3 | This file attempts to document the compatibility issues between |
---|
4 | different Subversion clients and servers. More specifically, where we |
---|
5 | want to change our (WebDAV) protocol usage in an incomptabile way, and |
---|
6 | our stepwise plan towards rolling out that change. |
---|
7 | |
---|
8 | |
---|
9 | BINARY PROPERTIES |
---|
10 | ================= |
---|
11 | |
---|
12 | Change: to signify that a property is binary, we will add an attribute |
---|
13 | onto the property element that specifies its encoding (base64 |
---|
14 | or standard XML entity escaping). |
---|
15 | |
---|
16 | Problem: old clients and servers will not be looking for this |
---|
17 | attribute, and will not decode the contents appropriately. |
---|
18 | |
---|
19 | The current plan from issue 1015: |
---|
20 | --------------- |
---|
21 | Okay, I've decided to propagate this functionality in three stages, |
---|
22 | with a couple of milestones between each stage: |
---|
23 | |
---|
24 | (1) server and client learn to recognize and handle the new |
---|
25 | 'V:encoding' attribute on properties. at this point, no binary |
---|
26 | properties will actually be coming across the ra-dav wire. (0.20 |
---|
27 | milestone) |
---|
28 | |
---|
29 | (2) server starts to transmit non-XML-safe properties with the |
---|
30 | 'V:encoding="base64"' attribute and the property value |
---|
31 | base64-encoded. during this interim period, clients will be to get |
---|
32 | binary properties from the server, but will not be able to commit |
---|
33 | new or modified binary properties. (0.21 milestone) |
---|
34 | |
---|
35 | (3) clients starts to transmit non-XML-safe properties with the |
---|
36 | 'V:encoding="base64"' attribute and the property value |
---|
37 | base64-encoded. this is the moment of full support. (0.22 |
---|
38 | milestone) |
---|
39 | |
---|
40 | All the code for full support will be in place, but disabled |
---|
41 | functionality will be wrapped in SVN_DAV_FEATURE_BINARY_PROPS |
---|
42 | #defines. |
---|
43 | |
---|
44 | When stage 2 is ready to go into 0.21, we just remove the #defines |
---|
45 | from the code in mod_dav_svn, commit, and reset this issue to have a |
---|
46 | 0.24 milestone. |
---|
47 | |
---|
48 | When stage 3 is ready to go into 0.22, we just remove the #defines |
---|
49 | from the code in libsvn_ra_dav, lose the #define itself from |
---|
50 | svn_dav.h, commit, and close this issue. |
---|
51 | --------------- |
---|
52 | |
---|
53 | |
---|
54 | REPOSITORY UUIDS |
---|
55 | ================ |
---|
56 | |
---|
57 | Change: |
---|
58 | |
---|
59 | Problem: |
---|
60 | |
---|
61 | Plan: |
---|
62 | |
---|
63 | |
---|
64 | PROPERTY NAMESPACES |
---|
65 | =================== |
---|
66 | |
---|
67 | Change: |
---|
68 | |
---|
69 | Problem: |
---|
70 | |
---|
71 | Plan: |
---|
72 | |
---|
73 | |
---|
74 | HANDLING OF UNKNOWN XML ELEMENTS |
---|
75 | ================================ |
---|
76 | |
---|
77 | Change: |
---|
78 | |
---|
79 | Problem: |
---|
80 | |
---|
81 | Plan: |
---|
82 | |
---|
83 | [note: need to review any "else" conditions to ensure we don't fall |
---|
84 | into them for unknown/future props; some if constructs might have |
---|
85 | assumed only (say) three elements were possible, so only tested for |
---|
86 | two of them, and fell to the else for the third] |
---|