Presentation is loading. Please wait.

Presentation is loading. Please wait.

WebDAV MERGE method use cases. Merge with simple conflict To merge main.c from the bugfix workspace into the project1 workspace the client would issue.

Similar presentations


Presentation on theme: "WebDAV MERGE method use cases. Merge with simple conflict To merge main.c from the bugfix workspace into the project1 workspace the client would issue."— Presentation transcript:

1 WebDAV MERGE method use cases

2 Merge with simple conflict To merge main.c from the bugfix workspace into the project1 workspace the client would issue a MERGE request with the target being /dav/vcr/project1/main.c and DAV:source being /dav/vcr/bugfix/main.c. This would CHECKOUT the VCR in the project1 workspace, and set it’s DAV:merge-set to include V2.2 and V4. It is the clients responsibility to physically merge the file contents and properties (PUT and PROPPATCH the checked-out VCR) and move the version URLs from the merge-set to the predecessor-set. The client must then explicitly CHECKIN the VCR. This is described in the protocol in the postcondition DAV:checked-out-for-merge. Version History Resource /dav/his/h1 V4 V3 V1 V2 V2.1 V2.2 Version Controlled Resource /dav/vcr/bugfix/main.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V2.2. Version Controlled Resource /dav/vcr/project1/main.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. DAV:checked-in

3 Merge with no conflict The file foo.c has been edited to create V4 in a “bugfix” workspace and that fix needs to be included back into the main project1 workspace. The client would issue a MERGE request with target being /dav/vcr/project1/foo.c and DAV:source being /dav/vcr/bugfix/foo.c. This would simply UPDATE the VCR /dav/vcr/project1/foo.c so that it’s content and dead properties reflect that of V4 and it’s DAV:checked-in version would be V4. This is described in the protocol on the postcondition DAV:descendant-version. V4 V3 V1 V2 Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V3. DAV:checked-in Version Controlled Resource /dav/vcr/bugfix/foo.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V4.

4 No merge needed The file foo.c has been edited to create V4 in the “project1” workspace and the bugfix workspace is being merged back into the main project1 workspace. The client would issue a MERGE request with target being /dav/vcr/project1/foo.c and DAV:source being /dav/vcr/bugfix/foo.c. This would not result in any UPDATE or CHECKOUT operation since V4 is a descendent of V3 and by definition there is no need for a merge. This is described in the protocol as postcondition DAV:ancestor-version. V4 V3 V1 V2 Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. DAV:checked-in Version Controlled Resource /dav/vcr/bugfix/foo.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V3.

5 No changes made The file foo.c has not been edited in either workspace and the checked-in versions of the VCRs point to the same version. If the client makes a MERGE request on either VCR no CHECKOUT or UPDATE will take place. I cannot see a pre or post condition covering this in the protocol but it seems logical. V4 V3 V1 V2 Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. DAV:checked-in Version Controlled Resource /dav/vcr/bugfix/foo.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is also V4.

6 Merge of two collections In this scenario the client wants to merge a whole directory structure of code from the bugfix workspace into the project1 workspace. The checked-in versions of the files may differ in the different workspaces and the bugfix workspace does not contain the file inc.h. The client should issue a MERGE request with /dav/vcr/project1/build as the target and /dav/vcr/bugfix/build as the DAV:source. For each member of the source collection the server will find a VCR (if any) in the target collection that points to the same version history. The server will CHECKOUT or UPDATE each VCR in the project1 workspace setting their DAV:merge-set. The client is responsible for updating the checked-out VCRs properties and content, setting their predecessor set and checking them back in again. Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg Collection Resource /dav/vcr/bugfix/build foo.c main.c images splash.jpg This collection has members that are VCRs for foo.c, main.c and inc.h, it also contains another collection called images which in- turn includes a VCR for the file splash.jpg. This collection includes members that are VCRs for the files foo.c and main.c, it also contains the images collection which also includes a VCR for the file splash.jpg.

7 Merge of additional files In this scenario the client wants to merge a whole directory structure of code from the bugfix workspace into the project1 workspace. The source collection has an additional file glob.c but according to the definition of the deltav MERGE method the new VCR would not be included in the target (because there is no VCR which shares the same Version History in the target collection). This seems wrong, the client must manually copy the resource to get it into the project1 workspace. See the 5 th paragraph of section 11.2 (but this is not defined in any pre or post condition. Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg Collection Resource /dav/vcr/bugfix/build foo.c main.c This collection has members that are VCRs for foo.c, main.c and inc.h, it also contains another collection called images which in- turn includes a VCR for the file splash.jpg. This collection includes members that are VCRs for the files foo.c and main.c, it also contains the images collection which also includes a VCR for the file splash.jpg. inc.h images splash.jpg glob.c

8 Merge with multiple sources In this scenario the client wants to merge two specific files from the bugfix workspace into the project1 workspace. The checked-in versions of the files may differ in the different workspaces. The client should issue a MERGE request with /dav/vcr/project1/build as the target and /dav/vcr/bugfix/build/foo.c and /dav/vcr/bugfix/build/inc.h as the DAV:source. For each VCR in the DAV:source property the server will find a VCR (if any) in the target collection that points to the same version history. The server will CHECKOUT or UPDATE each VCR in the project1 workspace setting their DAV:merge-set. The client is responsible for updating the checked-out VCRs properties and content, setting their predecessor set and checking them back in again. Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg This collection has members that are VCRs for foo.c, main.c and inc.h, it also contains another collection called images which in- turn includes a VCR for the file splash.jpg. Version Controlled Resource /dav/vcr/bugfix/build/foo.c Version Controlled Resource /dav/vcr/bugfix/build/inc.h


Download ppt "WebDAV MERGE method use cases. Merge with simple conflict To merge main.c from the bugfix workspace into the project1 workspace the client would issue."

Similar presentations


Ads by Google