Conference smurf::buildhelp

1343.0. "fyi: Re: Merging code different pools" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Fri Mar 17 1995 16:33

Date Of Receipt: 	16-MAR-1995 13:54:26.80
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  16-Mar-1995 1353"
To: 	odehelp@DEC:.zko.flume
CC: 	[email protected]
Subj: 	fyi: Re: Merging code different pools

Martin, I've fwd'd your mail to odehelp - some people (DECwest) may 
be interested.

I think you may also be able to use a check-out-config type of rev path
(but I'm not sure) with bco -j

i.e.	bco -jA;B;C:D;E;F file

where if A isn't found, it looks for B, else C; same for D;E;F

try it...

-josh


------- Forwarded Message

Return-Path: [email protected] 
Delivery-Date: Thu, 16 Mar 95 12:39:25 -0500
Return-Path: [email protected]
Received: from alpha.zk3.dec.com by flume.zk3.dec.com; (5.65/1.1.8.2/16Jan95-0946AM)
	id AA32378; Thu, 16 Mar 1995 12:39:24 -0500
Received: from avalon.Eng.PKO.DEC.Com by alpha.zk3.dec.com; (5.65/1.1.8.2/15Sep94-0303PM)
	id AA09092; Thu, 16 Mar 1995 12:39:23 -0500
Received: from localhost by avalon.eng.pko.dec.com; (5.65/1.1.7.2/22Nov94-1009PM)
	id AA09199; Thu, 16 Mar 1995 12:38:36 -0500
Message-Id: <[email protected]>
To: Joshua M. Friedman OSF/UNIX SDE <[email protected]>
Subject: Re: Merging code different pools 
In-Reply-To: Your message of "Thu, 16 Mar 95 10:57:02 EST."
             <[email protected]> 
Date: Thu, 16 Mar 95 12:38:36 -0500
From: [email protected]
X-Mts: smtp


thanks
  I had actually wandered down this path and started doing bco -jv1:v2 -km.


I have found an interesting problem with this though.  If v1 and v2 are 
symbolic revision names then:
	- If v1 does not exist in the rcs file bco exits with status of 1
	  which is ok. in this case bco -j1.1:v2 will create the correct file.
	- If v1 does exist in the rcs file, then v1 must be an ancestor of
	  the current version of file in this pool or bco generates an
	  empty file.


It seems to me that programmers must have to submit the same files to multiple
pools on a regular basis(particulary when there is a pool for the currently
shipping product and a pool for the product under development).

Most often, existing files in these pools will be identical.
Sometimes,  existing files are slitely different.
Sometimes,  a new file needs to be submitted to both pools.

It seems reasonable that:
	- when files are identical in two pools the resulting files
	  should be the same with the exception of the comment(version/date).
	- when a file is new, the same file/base level should be able
	  to be used in the two pools.
	- when files differ in two pools the resulting file contains the
	  proper changes and the history info from each version is maintained.

Up till this point, I seem to always end up with all of the comments from
all of the submits ending up in the pool I submitted to last.




I am trying to whip up a little script for submitting files to another pool
using the tlog file generated from an earlier bsubmit.  It actually works
reasonably well, if you know symbolic names associated with the different
pools.  This information has not been generally known in the OPEN3D group.


I am also interested in developing an automatic process for merging submission
from our shipping(ie. bug fix) pool into our main line(ie. development) pool.
Programmers should rarely have to submit files twice. 

------- End of Forwarded Message