Re: A question about branching, merging

jamsden@us.ibm.com
Mon, 6 Dec 1999 10:39:13 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525683F.00561006.00@d54mta03.raleigh.ibm.com>
Date: Mon, 6 Dec 1999 10:39:13 -0500
Subject: Re: A question about branching, merging



Bob,
No need to apologize for any questions. Version management is hard. See
responses to your questions below in <jra> tags.





bob mcwhirter <bob@werken.com> on 12/03/99 08:53:58 PM

To:   ietf-dav-versioning@w3.org
cc:

Subject:  A question about branching, merging




Hello-

Please pardon the probably rudimentary questions, but
I've read the specs for DAV and DeltaV as best I could,
and I still have some questions.

I'm looking into building DAV/DeltaV aware/enhanced/powered
build-management tools.

Anyhow...

I'm curious as to how merging is accomplished using DeltaV.
<jra>
The need for merging results when activities, or other revision selectors
are added to a workspace revision selection rule that results in the
possibility of selecting revisions that are on different lines of descent.
The workspace can produce a conflict report which lists all the resources
that need to be merged.

Given the merge conflict report, you can use the MERGE method to set the
merge successor/predecessor relationship, and checkout the target revision.
We will not be doing any auto-merging as that is typically a client
operation requiring human interaction, and is very document type dependent.
The details of the method are not known as yet since we just decided to
include it at the Washington IETF meeting. The user makes whatever changes
are necessary to effect the merge and checks in the result to create a new
revision.

Once the merge has been done, the new revision establish a common line of
descent which eliminates the conflict from the workspace conflict report.
</jra>


From what I can understand in the spec, a CHECKIN of a file
does not imply any merging.
<jra>
That is correct. Merging cannot be required on checkin because there may be
other dependent resources that need to be merged in order to create a
consistent state, and there may not be enough information available for the
user checking in the revision to do the merge at checkin time. Doing a
specific merge operation allows users to have better control over when
things are merged, and what is merged.
</jra>

Given a resource /index.html (rev1), I can check it out, someone
else can check it out, into our own workspaces.

The other person makes edits, and checks in (creating rev2)
and I then checkin my edits (creating rev3).

There seem to now be two revision chains:

     rev1 -> rev2

     rev1 -> rev3

With no corralation between rev2 and rev3, aside from a
common ancestor.  (Is this correct?)
<jra>
Yes.
</jra>

The spec seems to do some Hand Waving to say that these
could be merged at a later time, but I can't figure out how.
<jra>
See above.
</jra>

Ideally, I'd like to be able to merge rev2 and rev3, creating
rev4.  Would it be the case that the client performs the
merges, sets predecessor attributes accordingly, and adds
rev4 to the server?  While the server reamins blissfully unaware
of *any* correlation between any of the resources?
<jra>
That's what merge does, but the server is aware of the lines of descent for
any revision including merge predecessor/successor relationships. This is
required to maintian the history of the versioned resource, and to resolve
the merge conflict in the workspace.
</jra>

If my first assumption is incorrect, and I have to perfrom
a merge to create rev3, then I must question how to implement
branching semantics.

If required:

     rev1 -> rev2 -> rev3

then is there really a way to allow checkpointing in
workspaces (creating revisions) without causing merge headaches?

I guess my question really boils down to where the semantics
of your revision control system come into place.

Or does DeltaV not really attempt to address the issue of
'conflicts' 'branches' and 'merges', instead, leaving that
up to implementing in the client tools?
<jra>
The server does address conflicts, activities, and merging. However,
clients are free to ignore these functions and do their own merging. In
additon, merge and activity support will be one of the optional server
features.
</jra>

Thanks for your time.

     -bob mcwhirter

     (btw, anyone else have an active interest in
     investigating build-management and DeltaV/DAV?)
<jra>
Build management is an interesting topic, one we have choosen to defer. We
believe that DELTA-V includes all the information and services required to
support build management. I would suggest a separate specification of a
build manager would be appropriate as not all WebDAV versioning servers
will require it. This will provide the necessary interoperability while
decoupling it from core versioning semantics.
</jra>