RE: Merge Management

[Chuck . Irvine]

We have a config management person who does your merges. He then 
actually checks in the files with merge conflicts and sends out merge 
conflict mail notifications to the persons who last checked in the 
offending files. (CVS forces you to touch the files before you can 
check them in.) This seems to work fine for us.

> -----Original Message-----
> From: zsmith [mailto:address@hidden
> Sent: Wednesday, April 25, 2001 12:29 PM
> To: info-cvs
> Cc: zsmith
> Subject: Merge Management
> 
> 
> I am the build engineer for my company and one of the things that I
> am currently working on is a Source Control Strategy which defines
> things like when we branch, when and how we tag, and basically just
> lays out the does and don't-s of the source control system (which is
> currently CVS).
> 
> 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.  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?
> 
> -zach
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>