RE: Merge Management

[Chuck . Irvine]

You are right, of course, about destabilization. For this reason, we 
almost always make conflict resolution our top priority. When this 
isn't possible an alternative would be to branch off of your stable 
stream and merge to this. After you've resolved merge conflicts, you 
should be able to merge to the stable stream with little or no 
conflicts. You might get some arising from conflicting modifications on 
the new and stable streams. 

> -----Original Message-----
> From: zsmith [mailto:address@hidden
> Sent: Wednesday, April 25, 2001 1:50 PM
> To: Chuck.Irvine
> Cc: zsmith; info-cvs
> Subject: Re: Merge Management
> 
> 
> it does not surprise me, i just wanted to make sure i was reading it
> right.  i suppose i am a little bit hesitant to do this 
> because checking
> in files with conflict markers would surely destabilize what might be
> otherwise stable code, but i certainly see how this could ease merge
> management.
> 
> thanks
> 
> -zach
> 
> On Wed, Apr 25, 2001 at 01:18:24PM -0500, 
> address@hidden wrote:
> > Yes, we check them in. It's much easier then sending the 
> out the actual 
> > files. Why does this surprise you?
> > 
> > > -----Original Message-----
> > > From: zsmith [mailto:address@hidden
> > > Sent: Wednesday, April 25, 2001 1:04 PM
> > > To: Chuck.Irvine
> > > Cc: zsmith; info-cvs
> > > Subject: Re: Merge Management
> > > 
> > > 
> > > you check in the files with the conflict markers and the 
> person who
> > > needs to fix it can then check them out?  am i reading that right?
> > > or do you send the person who needs to fix the conflict 
> the file with
> > > the conflict markers in it and then check in their fixes?
> > > 
> > > -zach
> > > 
> > > On Wed, Apr 25, 2001 at 12:59:54PM -0500, 
> > > address@hidden wrote:
> > > > 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
> > > > > 
> > > 
> > > 
> > > -- 
> > > 
> > > CONFIDENTIALITY NOTICE:  The information in this electronic mail
> > > transmission contains confidential information intended only 
> > > for the use
> > > of the individual or entity named above.  If the reader of 
> > > this message
> > > is not the intended recipient, you are hereby notified that any
> > > dissemination, distribution or copy of the transmission 
> is strictly
> > > prohibited.
> > > 
> 
> 
> -- 
> 
> CONFIDENTIALITY NOTICE:  The information in this electronic mail
> transmission contains confidential information intended only 
> for the use
> of the individual or entity named above.  If the reader of 
> this message
> is not the intended recipient, you are hereby notified that any
> dissemination, distribution or copy of the transmission is strictly
> prohibited.
>