Re: Merge Management

[Zachary M. Smith]

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.