Re: Branching Scenarios

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 21 Feb 1999 14:25:57 -0500 

Date: Sun, 21 Feb 1999 14:25:57 -0500
Message-Id: <9902211925.AA03584@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <9901199194.AA919487591@SMTPGwy.MERANT.com>
Subject: Re: Branching Scenarios


Note: I described in a preceding message how DAV:branch and
DAV:secondary-branch properties could be used to produce the
exact behavior Brad wants to see.  So, from a protocol perspective,
I believe there is no issue here.  But I do have some comments
about the merge issues Brad has raised.

So read on only if you care about a "branching style" discussion,
which has nothing to do with the protocol (:-).

......

   From: Bradley.Sergeant@merant.com

   Let's say I take your second suggestion in supporting CASE 1 below.  
   V2 users work the mainline and V1 bug fixing is done in a V1 activity. 
   Your assumption appears to be that each activity would create a new 
   branch for the first revision of each resource checked out in the 
   activity, i.e. the branching policy described under TRY1 below.  Fine, 
   let's go with that for now.

   Each V1 change will create a revision off the mainline on a new 
   branch.  Because the CASE 1 policy is that all V1 changes are 
   immediately reflected in V2 (the mainline) each consistent set of V1 
   changes needs to be merged back into the mainline.  This results in 
   lots of short branches merged immedately back to the mainline, usually 
   with no intervening revisions.

If there have been no changes on the mainline, then the merge is trivial
and shoulc be automatic for even the most basic merge tools.  If there have
been intervening changes on the mainline, then the human is stuck with a
real merge, whether they like it or not.

        Further changes to V1 on a previously 
   V1 modified branch would require a subsequent merge onto the mainline. 

Again, either the change is trivial and automatic if there have been no
changes to the mainline since the V1 branch was last merged, or there have
been changes to the mainline, and the human is stuck with a real merge.

   Subsequent merges like this build on previous merges and the user may 
   find himself remerging items, depending on the sophistication of the 
   merge tool and the willingness to trust previous human merge 
   operations.  This is unavoidable in the case where V2 changes have 
   occurred on the same resource.

Agreed.

        It is completely unnessary otherwise, 
   but the forced branch policy of activity V1 requires it.

As above, I even a simple-minded merge tool could detect that
there have been no changes since the last time the branch has been merged
(just look at the predecessor and merge-predecessor relations),
and therefore it can just automatically make a copy in this case
without any human intervention.

Cheers,
Geoff