Title: WebDAV MERGE method use cases
1WebDAV MERGE method use cases
2Merge 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 DAVsource being
/dav/vcr/bugfix/main.c. This would CHECKOUT the
VCR in the project1 workspace, and set its
DAVmerge-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 DAVchecked-out-for-merge.
3Merge with no conflict
This is a VCR for main.c in workspace project1.
Its checked-in version is V3.
This is a VCR for main.c in workspace bugfix.
Its checked-in version is V4.
DAVchecked-in
DAVchecked-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
DAVsource being /dav/vcr/bugfix/foo.c. This
would simply UPDATE the VCR /dav/vcr/project1/foo.
c so that its content and dead properties
reflect that of V4 and its DAVchecked-in
version would be V4. This is described in the
protocol on the postcondition DAVdescendant-versi
on.
4No merge needed
This is a VCR for main.c in workspace project1.
Its checked-in version is V4.
This is a VCR for main.c in workspace bugfix.
Its checked-in version is V3.
DAVchecked-in
DAVchecked-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 DAVsource 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
DAVancestor-version.
5No changes made
This is a VCR for main.c in workspace project1.
Its checked-in version is V4.
This is a VCR for main.c in workspace bugfix.
Its checked-in version is also V4.
DAVchecked-in
DAVchecked-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.
6Merge 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 DAVsource. 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 DAVmerge-set.
The client is responsible for updating the
checked-out VCRs properties and content, setting
their predecessor set and checking them back in
again.
7Merge of additional files
foo.c
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.
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.
8Merge 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 DAVsource.
For each VCR in the DAVsource 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
DAVmerge-set. The client is responsible for
updating the checked-out VCRs properties and
content, setting their predecessor set and
checking them back in again.