| blob | 73c7dcb06e4d496c9b64f58ef7eded9420abecc2 |
4 <head>
13 </head>
15 <body>
20 <p>
21 This document details how WebDAV is used within the
23 product</a>. Specifically, how the client side interfaces with
25 WebDAV requests over the wire, and what the
26 server must do to map incoming WebDAV requests into operations
27 against the Subversion repository. Note that the server side is
28 implemented as an
30 operating as a back-end for its mod_dav functionality.
31 </p>
32 <p>
33 This document heavily refers to the
35 design document</a> and the
38 replicated here.
39 </p>
44 <tr>
45 <td>
47 communication, but the Subversion client is
49 fact, it expects some custom features from the
50 server. Further, the Subversion server is
53 DeltaV specification. A WebDAV or DeltaV client may very
54 well be able to interoperate with it, but only if that
55 client operates within the narrow confines of those
56 features the server has implemented.
57 </td>
58 </tr>
59 <tr>
60 <td>
61 Version 2.0 of Subversion will address WebDAV
63 features). Each of the custom features expected by the
64 client actually has an alternate mechanism available in
65 DeltaV, but in a much less efficient form.
66 </td>
67 </tr>
68 <tr>
69 <td>
70 It is expected that Version 1.0 will support read-only,
72 increase DeltaV interoperability will be considered.
73 </td>
74 </tr>
75 </table>
77 <p></p>
80 <p>
81 Subversion uses a tree-based format to describe a change set
82 against the repository. This tree is constructed on the client
83 side (by "walking" over the working copy) to describe the
84 change. The tree is marshalled to the server as a linear
85 sequence of changes to be applied to the repository. The
86 repository can accept changes in a random-access manner, so the
87 mapping from a tree to a set of changes works very well for the
88 repository.
89 </p>
90 <p>
91 Subversion provides properties on files, directories, and even
92 the abstract concept of a revision. Each of the operations
93 involving properties are mapped directly to WebDAV properties,
94 which are manipulated with the <span
98 revision properties are available through a <span
100 </p>
101 <p>
102 The Subversion server can efficiently compute deltas between two
104 deltas</span>, not simple text deltas). DeltaV does not have a
105 direct analogue for the tree delta concept. A client could
106 discover changes by issuing a sequence of <span
108 resources, but this would be a time-consuming operation,
109 involving many requests. Instead, Subversion marshals this
110 concept as a custom WebDAV <span
112 which items in the working copy are out of date and can issue
115 </p>
116 <p>
117 Tags and branches are simple copies in Subversion, which are
119 </p>
121 <p>need to talk about copies somewhere. need to discuss how copy
122 history is retained (svn does it automatically, but interop with
123 other servers may require us to set a custom property on those
124 servers.</p>
125 </blockquote>
128 <p>
129 Subversion uses many of the DeltaV concepts, as listed
130 below. Note that many of these concepts are not fully
131 implemented by Subversion; we have implemented enough to meet
132 our needs, but little more.
133 </p>
134 <dl>
136 <dd>
138 </dd>
141 <dd>
143 </dd>
146 <dd>
148 </dd>
151 <dd>
153 </dd>
156 <dd>
158 </dd>
161 <dd>
163 </dd>
166 <dd>
168 </dd>
171 <dd>
173 </dd>
176 <dd>
178 </dd>
181 <dd>
183 </dd>
185 </dl>
188 <p>
189 The very first concept to define is how a project is exposed to
190 the client. Subversion will expose all projects as URLs on a
191 server. The files and subdirectories under this project will be
192 exposed through the URL namespace.
193 </p>
194 <p>
195 For example, let us assume that we have a project named
196 "example". And let us say that this project will be exposed at
197 the URL:
199 </p>
200 <p>
201 This mapping is set up through a set of configuration
202 parameters for the Apache HTTP Server (which is hosting the
203 Subversion code and the particular project in question). The
204 configuration could look like:
205 </p>
206 <blockquote>
208 DAV svn
209 SVNPath /home/svn-projects/example
211 </blockquote>
212 <p>
213 Files and directories within the project will be directly mapped
214 into the URL namespace. For example, if the project contains a
216 file will be
218 </p>
221 <p>
222 When the user performs the initial checkout of a Subversion
223 project, the client will issue a series of <span
226 the repository, pick up some necessary metadata, and then fetch
227 the latest revision.
228 </p>
230 describe the OPTIONS request for fetching the activity
231 collection set. describe the sequence of PROPFINDs to reach the
232 baseline collection.
233 </p>
236 When the initial checkout was performed, Subversion fetched
238 and stored it as a property on each directory in the working copy.
239 property for each
240 collection. This property lists all of the locations on the
241 server where an activity may be created. The first of these
242 locations will be stored on the client for use during the commit
243 process.
244 </p>
246 Should probably describe the metadata we fetch, and how a
247 checkout of "not the latest" (e.g. by date or revision) will
248 work.
249 </p>
252 <p>
253 Subversion commits are modeled using the "activity" concept from
254 DeltaV. An activity can be viewed as a transaction for a set of
255 resources.
256 </p>
259 <p>
260 At commit time, the Subversion client will retrieve the stored
262 know where it should create the activity. Next,
263 the client will generate a UUID (a unique value) to use for the
264 activity's location. Finally, the client will issue a
266 composed from the activity location and the UUID. This request
267 will construct an activity to hold all of the changes for the
268 commit.
269 </p>
271 <dl>
273 <dd>
278 </dd>
280 <dd>
282 <span class="url">http://www.example.com/repos/foo/$svn/act/01234567-89ab-cdef-0123-456789abcdef</span></div>
284 </dd>
285 </dl>
286 <p>
288 activity to use upon checkout. This feature is used to associate
289 all items with the newly-created activity.
290 </p>
294 talk about checking out the baseline and applying a PROPPATCH to
295 the working baseline.
296 </p>
299 <p>
300 A change set in Subversion is specified with a "tree delta" (see
301 the SVN design for more details on the changes that can be
302 placed into a tree delta). The tree delta will be unravelled
303 into a set of requests. These requests will be one of the
304 following forms:
305 </p>
306 <dl>
308 <dd>
309 These changes are mapped onto a <span
311 of the target's parent collection is checked out using the
313 activity). The target (name) is then deleted from the
314 resulting working collection using the <span
317 <p></p>
318 </dd>
321 <dd>
322 This is modeled by performing a <span
324 target's parent collection. The new file is created within the
325 resulting working collection using a <span
329 <p></p>
330 </dd>
333 <dd>
334 This is modeled by performing a <span
336 target's parent collection. The new directory is created
337 within the resulting working collection with a <span
341 <p></p>
342 </dd>
345 <dd>
348 <p>
349 A tree delta can specify that a file/directory originates as
350 a copy of another file/dir. This copy may be further
351 modified by additional elements the tree delta.
352 </p>
353 <p>
354 This change will be modeled by performing a
356 collection which will contain the new resource. The
358 version-controlled resource (VCR) within the working
360 property referring to the ancestor's version resource.
361 </p>
362 <blockquote>
365 working collection. This will create a new version history
366 which is then placed into the working collection. The
368 property to specify the version resource of the ancestor.</p>
370 <p>
371 Because a version resource does not specify the revision,
373 resource into the working collection -- it will not tell
374 us what revision was copied. Instead, we will most likely
375 copy a version resource out of the appropriate
376 baseline. This implies the client must be able to map from
377 a URL/revision pair to a baselined version resource URL.
378 </p>
379 <p>
380 The second issue is whether/how we set the
382 history. Or, more precisely, how we synthesize the value
383 from information stored in the repository. This is still
384 under investigation.
385 </p>
386 </blockquote>
387 </dd>
390 <dd>
391 This change does not have a WebDAV modeling because tree
392 deltas model it as two, sequential operations: a
395 <p></p>
396 </dd>
399 <dd>
400 This change does not have a WebDAV modeling because tree
401 deltas model it as two, distinct operations: a
404 <p></p>
405 </dd>
408 <dd>
410 the target's version resource, followed by a <span
413 <p></p>
414 </dd>
417 <dd>
418 In Subversion terms, "replace directory" means that additions,
420 directory. Each of these changes are modeled individually, and
421 the change to the directory is performed
422 implicitly. Therefore, this "change" has no particular mapping
423 into WebDAV.
425 <p></p>
426 </dd>
429 <dd>
430 A property delta (against a file or directory) maps directly
432 terms. The target's version resource will be checked out using
435 resulting working resource.
436 </dd>
437 </dl>
440 <p>
441 The final action of the commit process is to issue a <span
443 specifying that the activity (created earlier) be checked in and
444 the corresponding version-controlled resources be updated to
445 refer to the new version resources.
446 </p>
448 the comment below is not quite right. talk about the working
449 baseline, and how that is used to create a new baseline (with
450 the commit message on it)
451 </p>
452 <p>
453 The version-controlled resources are also baseline-controlled,
454 which means that updates to them will automatically create a new
455 baseline. In essence, the commit will create a new baseline
456 corresponding to the new Subversion revision.
457 </p>
462 reflect some recent changes to the SVN-to-DAV mapping. Consider
463 it out of date until this warning is removed.
464 </p>
465 <p>
466 Consider the following set of operations and its corresponding
467 tree delta (taken from the SVN design document):
468 </p>
469 <ol>
473 </ol>
499 </pre>
501 <p>
502 Walking through this delta, we map out the WebDAV requests
503 listed below. The numbers in the above delta roughly correspond
504 to the numbered entries below. The correspondence is not exact
505 because a specific, resulting behavior is typically based on a
506 combination of a few elements in the delta.
507 </p>
508 <ol>
509 <li>
513 <p>
516 </p>
517 <p>
521 </p>
522 </li>
523 <li>
528 resource:
529 <p>
532 </p>
533 </li>
534 <li>
535 <p>
538 </p>
539 <p>
541 </p>
542 </li>
543 <li>
547 <p>
550 </p>
551 <p>
552 And now we copy the right directory into the new working
553 resource:
554 </p>
555 <p>
558 </p>
559 </li>
560 <li>
562 resources on the server, so we simply delete the part that we
563 don't want:
564 <p>
566 </p>
567 </li>
568 </ol>
571 <p>
572 The Subversion server exposes repositories at user-defined
573 URLs. For example, the "foo" repository might be located at
574 <span
576 the server also requires a number of other resources to be
577 exposed for proper operation. These additional resources will be
578 associated with each repository in a location under the main
579 repository URL. By default, this location is "<span
582 </p>
583 <blockquote>
585 DAV svn
586 SVNPath /home/svn-projects/foo
587 SVNSpecialURI .special
589 </blockquote>
590 <p>
592 we will expose several collections. Assuming we use the default
594 </p>
595 <dl>
597 <dd>
598 This area is where activity resources are created. The client
599 will pick a unique name within this collection and issue a
601 the activity in further interactions.
602 <p>
604 resource.
605 </p>
606 <blockquote>
609 enumerate the current activities.</p>
610 </blockquote>
611 <p>
612 Only a subset of methods are allowed on the activities
616 </p>
617 <p>
618 Per the Delta-V specification, all activity resources will
621 </p>
622 </dd>
625 <dd>
627 actually don't use version history resources. in the future,
628 they might be modeled like this</span>
630 <p>
631 This collection contains the version history resources for
632 files and directories in a project. Its internal layout is
633 completely server-defined. Clients will receive URLs into
634 this collection (or a subcollection) from various responses.
635 </p>
636 <p>
638 resource.
639 </p>
640 <p>
641 Internally, the URL namespace is laid out with URLs of the
642 following form:
643 </p>
646 </blockquote>
647 <p>
649 that Subversion uses to reference individual files and
651 defined by the Subversion repository. Note that this is an
652 undotted node id, which is the base for the entire history
653 of a given node in the repository.
654 </p>
655 <p>
658 </p>
661 quite correct. The issue of linking one version history to
662 another is still open. Further, I think that node 73 and
663 node 73.4.1 are each version histories (where the latter is
665 within the version history.</p>
666 </blockquote>
667 </dd>
670 <dd>
671 This collection contains the version resources for the
672 project.
674 <p>
676 resource.
677 </p>
678 <p>
679 The layout of this collection is internal to the server. For
680 reference purposes here (and to describe the
681 implementation), it is laid out as:
682 </p>
685 </blockquote>
686 <p>
687 Only read-only methods are allowed against these resources
690 </p>
691 <p>
693 simply the value of the resource at checkin time
696 </p>
697 </dd>
700 <dd>
701 This collection contains working resources for the resources
703 method. The form and construction of this collection is
704 server-defined, but is also well-defined so that clients may
705 interact properly with collection versions that have been
706 checked out.
707 <p>
709 resource.
710 </p>
711 <p>
712 For reference purposes, the working resource URLs are
713 constructed as:
714 </p>
717 </blockquote>
718 <p>
719 Any method is allowed on the working resources, but no
720 methods are allowed on any of its parents.
721 </p>
722 <p>
724 follows normal resource typing:
726 resources, and
728 for working collections.
729 </p>
730 </dd>
733 <dd>
736 <p>
737 version-controlled configuration...
738 </p>
740 <p>
742 </p>
743 </dd>
746 <dd>
749 <p>
750 baselines...
751 </p>
753 <p>
755 </p>
756 </dd>
759 <dd>
762 <p>
763 working baseline...
764 </p>
765 </dd>
768 <dd>
771 <p>
772 baseline collection...
773 </p>
774 </dd>
775 </dl>
779 this section needs to be reworked. the properties occur on the
780 FS revisions (and exposed via baselines).
781 </p>
782 <p>
783 As mentioned before, Subversion properties map onto WebDAV
784 properties. For history/log reporting, the following WebDAV
785 properties will be applied to each baseline (a Subversion
786 revision) and to each version resource created by the
787 revision. Since these resources are all version resources, the
788 properties below are read-only.
789 </p>
790 <dl>
792 <dd>
793 This is the standard (dead) property for specifying a checkin
794 comment.
795 <p></p>
796 </dd>
798 <dd>
799 This is a (dead) property that is generated from Subversion's
800 concept of the "user" who made a particular change.
801 <p></p>
802 </dd>
804 <dd>
805 This is a read-only live property created by the server at
806 commit time.
807 </dd>
808 </dl>
809 <p>
810 The history for a specified file will be generated using the
813 fetch the three properties mentioned above for each version of
814 the file/directory.
815 </p>
816 <p>
817 Based on the client design, it may be important to specify other
818 read-only live properties for information about versions. For
819 example, how many lines were added/removed in a particular
820 checkin for a file? Creating these live properties will be quite
821 straight-forward, and driven by the client design over time.
822 </p>
823 <blockquote>
824 <p>Note: if we do this, however, then we'd end up tying the client
825 to the server. Of course, if the client were run against another
826 DeltaV server which didn't report these properties, then we'd
827 simply not display them in the UI. (e.g. graceful degradation of
828 functionality)</p>
829 </blockquote>
832 <p>
833 After the initial checkout, the client can request a status
834 report (what has been changed on the client, pending a commit;
835 what has been changed on the server, pending an update). The
836 update process is similar, except that we also fetch the changes
837 from the server.
838 </p>
839 <p>
840 The local changes can be handled entirely on the client
841 side. The Working Copy library can easily handle the detection
842 and reporting of these changes. We're concerned with efficiently
843 detecting what has changed on the server.
844 </p>
845 <p>
846 While it would be possible to traverse the repository, fetching
847 the current state, and comparing that to the client state, it
848 would not be efficient. The Subversion design enables the server
849 to easily compute what has changed (relative to the client), if
850 it is given a description of the client state.
851 </p>
852 <p>
854 based on a custom Subversion-specific WebDAV report. This custom
855 report will transmit the state of the working copy to the
856 server, and the server response will specify which resources
857 will need to be updated (fetched).
858 </p>
859 <p>
861 custom XML body. The body will use the standard Subversion
862 technique of reporting a top-level revision number, and then
863 only reporting children that have different revisions. The
864 result of the report will use the same technique of reporting
865 only the resources where a change is found. If a change is
866 found, the server will provide a URL to the version resource to
867 fetch for the changed resource. The server will also report the
868 current revision number.
869 </p>
872 </blockquote>
873 <blockquote>
874 <p><small>
875 The custom report will tie the client to only those servers
876 which support the report, but a future version of the software
877 will contain a fallback codepath, a graceful degradation, to
878 support other DeltaV servers.
879 </small></p>
880 </blockquote>
881 <p>
882 When an updated is performed, the client will fetch each of the
884 response.
885 </p>
886 <p>
888 content in a "diff" format when possible. The mechanics of this
889 will follow the Internet Draft, titled
890 <a href="http://www.ietf.org/internet-drafts/draft-mogul-http-delta-10.txt">Delta Encoding in HTTP</a>.
891 </p>
894 <p>
895 Etags are required to be unique across all versions of a
896 resource. Luckily, this
897 is very easy for a version control system. Each etag will be
899 </p>
900 <p>
901 Etags are used to generate diffs, following the guidelines in
902 the aforementioned draft:
903 <a href="http://www.ietf.org/internet-drafts/draft-mogul-http-delta-10.txt">Delta Encoding in HTTP</a>.
904 The problem then becomes how to get the etag for each file
905 stored on the client (we don't need etags for directories since
908 the HTTP response headers for each file retrieved.
909 </p>
910 <p>
911 The other part of the problem is getting the etag after a
913 provides a way to request properties from the version resources
914 which are created as part of the checkin of the activity. The
915 etag (and other properties) can be fetched using that mechanism.
916 </p>
919 <p>
920 Tags and branches within Subversion are performed by copying
921 from one area to another. For example:
922 </p>
923 <blockquote>
924 <pre>
925 [.../src/my-project]$ svn cp trunk tags/1.0.3-rc4
926 [.../src/my-project]$ svn commit
927 </pre>
928 </blockquote>
929 <p>
931 considered readonly and will always reflect the status of
933 </p>
934 <p>
935 These copies are handled just like a regular commit. An activity
937 working resource is created via <span
941 merged back into the repository with a <span
943 </p>
948 DeltaV draft has gone through a number of revisions, and our use
949 of DeltaV has changed some.
950 </p>
953 <p>
954 The server will need to implement the following WebDAV methods
955 for proper operation:
956 </p>
957 <ul>
969 </ul>
970 <p>
971 The following methods are not required by Subversion at this
972 time:
973 </p>
974 <ul>
982 </ul>
985 <p>
986 The following DeltaV properties will be implemented:
987 </p>
988 <ul>
989 <!-- resource properties -->
997 <!-- version-controlled resource properties -->
999 <li>
1001 empty element (auto versioning not supported).
1002 </li>
1004 <!-- checked-out resource properties -->
1006 <li>
1008 <div><i>
1009 Note: the Subversion design document is not clear on the
1010 mechanics of how multiple predecessors are merged to create
1011 a single, new revision. When this clarifies, then
1013 than zero or one predecessor URLs
1014 </i></div>
1015 </li>
1017 <!-- version resource properties -->
1018 <!-- predecessor-set -->
1019 <li>
1021 (global) revision number.
1022 </li>
1026 <!-- checked-out (working resource) properties -->
1027 <!-- checkout-fork, checkin-fork -->
1029 <li>
1031 empty property (sub-baselines not supported).
1032 </li>
1033 <li>
1036 </li>
1038 <!-- vcc properties -->
1041 <!-- baseline properties -->
1042 <!-- subbaseline-set -->
1045 <!-- activity properties -->
1046 <li>
1048 empty property (sub-activities not supported).
1049 </li>
1051 <!-- version-controlled collection properties -->
1052 <li>
1054 (internal members can never be eclipsed).
1055 </li>
1056 </ul>
1058 <p>
1059 Contrary to the DeltaV specification, the following required
1060 properties will not be implemented:
1061 </p>
1062 <ul>
1063 <li>
1065 expensive operation to synthesize this value.
1066 </li>
1067 <li>
1069 what has actually been checked out, but use the working
1070 resource URL to provide the necessary information; thus we
1071 have no record of the data to populate this property.
1072 </li>
1073 <li>
1076 commit. It doesn't really support the arbitrary merging
1077 defined within the spec.
1078 </li>
1079 <li>
1082 </li>
1083 <li>
1085 activities are only used for working resources, so versions
1086 cannot be part of an activity.
1088 </li>
1089 <li>
1091 activities are only used for working resources, and we do not
1092 record what working resources "exist".
1093 </li>
1094 <li>
1096 activities are only used for working resources, so versions
1097 cannot be part of an activity.
1099 </li>
1100 <li>
1102 we do not have version history resources to include in the
1103 property.
1104 </li>
1105 </ul>
1108 <p>
1110 it supports the following DAV features:
1111 </p>
1112 <ul>
1122 </ul>
1125 <p>
1127 will signal support for the following reports:
1128 </p>
1129 <ul>
1132 </ul>
1133 <p>
1134 These reports are available only on the "public" resources (the
1135 VCRs). They are not available on the resources within the
1137 </p>
1140 <p>
1141 Discuss timeouts and auto-purge of activities (and the related
1142 working resources).
1143 <br/>
1144 Discuss the activity database maintained by mod_dav_svn.
1145 <br/>
1146 Discuss other implementation details of ra_dav and mod_dav_svn.
1147 </p>
1150 <p>
1151 Several times, people have asked, "Why choose
1152 HTTP/WebDAV/DeltaV? That seems awfully bloated and
1153 ill-suited. Why didn't you design a custom, well-tuned protocol?
1154 Or maybe use the CVS protocol?" Listed below are a number of
1155 reasons for our choice of WebDAV as our network protocol.
1156 </p>
1158 <blockquote>
1159 <p><small>
1160 While this list could certainly be expanded with more reasons
1161 (and to be fair, with a list of reasons why WebDAV was a poor
1162 choice), it certainly demonstrates the basic reasons for our
1163 choice.
1164 </small></p>
1165 </blockquote>
1167 <blockquote>
1168 <p><small>
1169 Note: this list came from an email note, so the tone and point
1170 of view might be a bit off. Further word-smithing is
1171 welcome...
1172 </small></p>
1173 </blockquote>
1176 <blockquote>
1177 <p>For example, take a
1178 look at:
1179 <a href="http://svn.collab.net/repos/svn/trunk/README">http://svn.collab.net/repos/svn/trunk/README</a>
1180 (that's the HEAD right there; we also have URLs for every
1181 previous revision of every file)</p>
1182 </blockquote>
1185 <blockquote>
1186 <p>Use Web Folders or WebDrive or somesuch on
1187 your Windows box (or Windows XP's native DAV mounts) to browse
1188 the SVN repository with Windows Explorer. Mac OS X has builtin
1189 DAV server mounting. Nautilus has DAV capabilities. Then you
1190 have your Open Source tools such as cadaver, Goliath, etc.</p>
1191 </blockquote>
1194 <blockquote>
1195 <p>I couldn't even begin to count the number of HTTP tools and
1196 libraries available. If we had designed our own protocol, then
1197 we would have /none/ of those benefits. Heck, two HTTP library
1198 implementors (Joe Orton of Neon, and Daniel Stenberg of CURL)
1199 are regulars here. we wouldn't get that benefit. I've used
1200 Python's httplib (and a davlib of my own) to do a lot of testing
1201 of our server. No need to go and roll new protocol libraries.</p>
1202 </blockquote>
1205 <blockquote>
1206 <p>One word: Ethereal :-) When we capture network traces, Ethereal
1207 already knows about HTTP. It's quite nice, but I know there are
1208 even better ones out there. But we also have other tools like
1209 squid and other (caching) proxies (see the next item).</p>
1210 </blockquote>
1213 <blockquote>
1214 <p>Subversion will work great with caching proxies. There is no
1215 longer a need for specialized tools like "cvsup". Just drop in a
1216 caching proxy, and you've already got your distributed read-only
1217 repository. That European dev team can just drop in the cache
1218 between them and the US server and their checkouts/updates will
1219 get cached for the benefit of the other team members. Commits
1220 will flow through, back to the US-based server.</p>
1221 </blockquote>
1224 <blockquote>
1225 <p>We don't have to reimplement an authentication scheme for a new
1226 protocol. We can use all of the various schemes that have been
1227 defined for HTTP. Ever look at the CVS protocol? Ever see the "I
1229 creating a new authentication scheme. But we get to use SSL and
1230 certificate-based auth if we want. Kerberos. NTLM. or even just
1231 simple Basic or Digest. And our users can come from text files,
1232 database, LDAP, or PAM. We don't have to reinvent the wheel cuz
1233 it is all available for Apache already.</p>
1234 </blockquote>
1237 <blockquote>
1238 <p>We don't have to worry about how to portably set TCP_CORK for
1239 optimal network packets. We don't have to worry about when
1240 sendfile() makes sense, or if it is available. We don't have to
1241 worry about dropped client connections, how to best use threads
1242 and processes to scale, request management, monitoring, logging,
1243 etc. Apache gives us all of that and a ton more. I *really*
1244 would not want to do that through xinetd. I mean... setting
1245 TCP_CORK on stdout? freaky :-)</p>
1246 </blockquote>
1249 <blockquote>
1251 switch. And we didn't do anything. The client library and server
1252 that we use just support it automatically for us, according to
1254 </blockquote>
1257 <blockquote>
1258 <p>In the future, we'll be able to interoperate with a multitude of
1259 IDEs and other WebDAV/DeltaV clients. As DeltaV becomes more
1260 prevalent, IDEs could very well use it for source code
1261 management, and we'll be right there without needing to write
1262 some MS/SCC library to interface to the tool.</p>
1263 </blockquote>
1265 <hr/>
1267 <!-- Created: Thu Aug 10 19:14:20 PDT 2000 -->
1268 <!-- hhmts start -->
1270 <!-- hhmts end -->
1272 </div>
1273 </body>
1274 </html>