Re: A question about branching, merging
Tim Ellison OTT (Tim_Ellison@oti.com)
Mon, 06 Dec 1999 10:15:14 -0500
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: bob@werken.com (bob mcwhirter),
Message-ID: <1999Dec06.101342.1250.1407397@otismtp.ott.oti.com>
Date: Mon, 06 Dec 1999 10:15:14 -0500
Subject: RE: A question about branching, merging
>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.
All questions are fair game for exposing areas that require further
explanation in the spec. Thanks for taking the time to send them.
>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.
The short answer is "manually" :-)
>From what I can understand in the spec, a CHECKIN of a file
>does not imply any merging.
Correct.
>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?)
This is correct -- and that they are also seen as distinct revisions of the
same versioned resource.
>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.
>
>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?
This is basically right. The client checks out the revisions and does
whatever makes sense in the application to merge them. This could be apply
all changes to the common successor, reject stale changes, etc. Since the
resources could be plain text, lines of code, binary or whatever it is safer
to put the onus on the client to figure out the merge semantics.
The client can set the 'merge-successors' to indicate from which revisions
this revision was merged. The server doesn't really care about these, they
are for the client's benefit in figuring out what happened. The
merge-successor values are mutable so they can be changed even after the
working resource becomes a revison -- there is a mutable
'merge-predecessors' too.
>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?
>
>Thanks for your time.
>
> -bob mcwhirter
>
> (btw, anyone else have an active interest in
> investigating build-management and DeltaV/DAV?)
There are a few people I suspect that have this interest -- myself included.
Regards,
Tim