Re: Merge Management

[Greg A. Woods]

[ On Wednesday, April 25, 2001 at 10:28:43 (-0700), Zachary M. Smith wrote: ]
> Subject: Merge Management
>
> One of the aspects of this document that I am dealing with is how to
> manage merges.  Most of the documentation that I have read (cvs and
> others) suggests that you have the person best suited to resolve conflicts
> do the merges.  This is commonly *not* the build engineer or the source
> control system admin, but is more likely the developers who wrote the code.
> That makes sense to me.

Indeed, and the more "senior" the person doing the merge, the better,
especially when merging from some "test" branch to any main branch where
releases will be cut from.

In two-phase commit systems, eg. Aegis, it is generally expected that
the senior developers will be responsible for approving and publishing
changes to the baseline (or rejecting them to be re-done by the
developer).

>  However, I am wondering if anybody has any thoughts
> on this topic or some suggestions for what has worked for them in the past.
> What I think i'd like to do is try to do the merges myself and delegate
> conflict resolution responsibilities to developers but CVS does not appear to
> have a very clean way of doing this.  Has anybody had any luck with doing 
> things this way?  Any tips or tricks to make it a bit smoother?

If you're also the superuser you could create working directories
containing the preliminary merges on behalf of the developer in question
and then have that developer resolve any conflicts, perhaps test the
result (or perhaps delegate that to someone else), and finaly commit any
outstanding changes in his or her own name.

That way the developers do not have to tag anything or know where to
start the merges from, etc.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>