Re: Versions being deleted during a MERGE...

Peter Raymond <Peter.Raymond@merant.com> wrote:

> I guess I would implement Tims idea and lock down all
> the resources before beginning the interactive merge.

MERGE has the potential to check out a great number of version-controlled
resources on the server and leave them around for the client to combine
multiple source versions into each.  This requires multiple round trips to
the server before the version-controlled resources are checked in again.
It is likely that one would only want to target MERGE on a personal
workspace, so that other users are not interferring with the (potentially
long running) manual merge process.

The sources of the merge are versions, so, assuming the target _is_ a
personal workspace, conflicts will only arise when the source versions are
deleted (as you pointed out).  On the sub-set of servers that support
version deletion it will be necessary for the client to lock those versions
to prevent them being deleted, or to 'skip' those resources that have
sources missing (which would simply require an UNCHECKOUT of the
version-controlled resource), and then re-apply the MERGE to get the new
set of sources.

If you choose to lock the versions you are ensuring that the results of the
merge reflect the state of the source and destination at the time the MERGE
method completed (clearly, while you are manually merging clients may be
creating new versions that would have influenced the results of the merge).
However, if you choose to 'skip' the resources that have missing versions
in the merge set, and then re-apply the MERGE you may never complete the
merge (if someone is constantly deleting versions that caused conflicts in
the results of the merge).

Given that you cannot simultaneously lock all the versions (identified by
the DAV:merge-set property on all the checked-out version-controlled
resources), and to reduce the requirements for a locking server, I'm more
inclined to make a guess that deleting conflicting versions is infrequent,
and simply retry the entire merge to get the latest server state.

Regards,
Tim

Received on Tuesday, 21 August 2001 04:59:32 UTC