[p4] Question about branching/integrating

Dave Lewis dlewis at vignette.com
Mon Jun 14 18:11:15 PDT 2004


  > From: David Rybolt <dagg at yahoo.com>
  > Cc: perforce-user at perforce.com
  > Sender: perforce-user-admin at perforce.com
  > Errors-To: perforce-user-admin at perforce.com
  > Precedence: bulk
  > List-Help: <mailto:perforce-user-request at perforce.com?subject=help>
  > List-Post: <mailto:perforce-user at perforce.com>
  > List-Subscribe: <http://maillist.perforce.com/mailman/listinfo/perforce-user>,
  > 	<mailto:perforce-user-request at perforce.com?subject=subscribe>
  > List-Id: Discuss Perforce with other users <perforce-user.perforce.com>
  > List-Unsubscribe: <http://maillist.perforce.com/mailman/listinfo/perforce-user>,
  > 	<mailto:perforce-user-request at perforce.com?subject=unsubscribe>
  > List-Archive: <http://maillist.perforce.com/pipermail/perforce-user/>
  > Date: Mon, 14 Jun 2004 13:08:41 -0700 (PDT)
  > 
  > 
  > --- Chuck Karish <chuck.karish at gmail.com> wrote:
  > > Branch from main at a point where you're sure that
  > > you'll take
  > > everything.   Integrate features from main to your
  > > new release branch
  > > as they're finished.
  > 
  > That won't work in this case, unfortunately.  The
  > 4.1.0 code was integrated into main _after_ some
  > changes were already added to main.  That means I
  > can't get all the 4.1.0 code integrated into my new
  > branch unless:
  > 
  >   1. I also integrate some of the new "main" stuff
  > (which I don't want).

not exactly true.  you could integrate all the stuff up to
the "some changes" you don't want, then you can integrate
all the stuff after that.  Of course, identifying the changenumbers
that fall into those categories might be difficult, but the
integration part could even be scripted.  

dave

  > 
  >   2. Or I branch from 4.1.0 .
  > 
  > However if I branch from 4.1.0, that'll make it hard
  > for me to integrate to/from main later.  I can get it 
  > to work with some baseless merges (-i or -I), but
  > there seems to be a lot of repetitive and hard
  > to manage conflict resolutions once I go down that
  > road.
  > 
  > > A more radical approach:  Make a permanent
  > > forward-development branch,
  > > and integrate features from //depot/dev only when
  > > theu're ready to be
  > > released.  The main line stays clean, the developers
  > > grumble about
  > > doing one more integration, the project managers
  > > love that release
  > > readiness is predictable and that they control
  > > release contents.
  > 
  > I'll likely utilize this approach at a latter
  > date, but I still fear issues like this:
  > 
  >   main 
  >     |
  >     +-- dev1
  >     |
  >     |
  >     +-- dev2
  > 
  > Both dev1 and dev2 are branched from main.  What do
  > I do if the dev1 folks want some of the dev2 code?
  > I can integrate dev2 to main, and then main
  > to dev1, but then my main codeline will have
  > some stuff that may or may not ever go to
  > production.  Alternatively, I can baseless
  > merge dev2 to dev1, but that will reintroduce
  > the long-term problems of baseless merging.
  > 
  > Dave
  > 
  > 
  > 	
  > 		
  > __________________________________
  > Do you Yahoo!?
  > Friends.  Fun.  Try the all-new Yahoo! Messenger.
  > http://messenger.yahoo.com/ 
  > _______________________________________________
  > perforce-user mailing list  -  perforce-user at perforce.com
  > http://maillist.perforce.com/mailman/listinfo/perforce-user
  > 



More information about the perforce-user mailing list