1 / 8

WebDAV MERGE method use cases

WebDAV MERGE method use cases. Version History Resource /dav/his/h1. Version Controlled Resource /dav/vcr/bugfix/main.c. Version Controlled Resource /dav/vcr/project1/main.c. V1. This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. V2.

blue
Download Presentation

WebDAV MERGE method use cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WebDAV MERGE method use cases

  2. Version History Resource /dav/his/h1 Version Controlled Resource /dav/vcr/bugfix/main.c Version Controlled Resource /dav/vcr/project1/main.c V1 This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. V2 This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V2.2. V2.1 V3 V2.2 DAV:checked-in V4 DAV:checked-in 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.

  3. Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c Version Controlled Resource /dav/vcr/bugfix/foo.c V1 V2 V3 V4 Merge with no conflict This is a VCR for main.c in workspace “project1”. It’s checked-in version is V3. This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V4. DAV:checked-in DAV:checked-in 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.

  4. Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c Version Controlled Resource /dav/vcr/bugfix/foo.c V1 V2 V3 V4 No merge needed This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V3. DAV:checked-in DAV:checked-in 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.

  5. Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c Version Controlled Resource /dav/vcr/bugfix/foo.c V1 V2 V3 V4 No changes made This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is also V4. DAV:checked-in DAV:checked-in 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.

  6. Collection Resource /dav/vcr/project1/build Collection Resource /dav/vcr/bugfix/build foo.c foo.c main.c main.c images inc.h splash.jpg images splash.jpg Merge of two collections 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. 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.

  7. Collection Resource /dav/vcr/bugfix/build Collection Resource /dav/vcr/project1/build Merge of additional files foo.c foo.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. main.c main.c inc.h inc.h glob.c images images splash.jpg splash.jpg 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 5th paragraph of section 11.2 (but this is not defined in any pre or post condition.

  8. Version Controlled Resource /dav/vcr/bugfix/build/foo.c Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg Merge with multiple sources 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/inc.h 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.

More Related