Conference smurf::buildhelp

1399.0. "fyi -- send him snaptrack" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Apr 18 1995 17:29

Date Of Receipt: 	11-APR-1995 14:26:56.89
From: 	SMURF::FLUME::"[email protected]"
To: 	flume::odehelp
CC: 	
Subj: 	fyi -- send him snaptrack

fyi,
I sent Chip a copy of snaptrack as well.
It is one of my favorite tools.

Tina

From:	DECWET::ANDERSON     "Tina Anderson"   11-APR-1995 11:15:57.96
To:	mmsrv::cdancy
CC:	anderson
Subj:	FWD: ODE Admin question

Hi.  

Yes, this is the case.  


			                 near-term-tree  <--- (1) submit here
                                               ^
                                               |
			later-release/link ----          <--- (2) need to relink here

If both are shared sandboxes, what is the near-term-tree
backed to? (you mentioned it was a shared sandbox as well)

On another issue:

If someone submit's to the near-term-tree, and
you already have a submit to the later-release, you are not going
to pick up the bugfix in the later-release.  Are developers making bugfix submits
to both later-release and near-term-tree?

Another way you could do this is back later-release to a stable baselevel of
near-term-tree.  weekly or bi-weekly create a new baselevel of near-term-tree.
retarget later-release to the new baselevel.  Then, bring later-release uptodate
with the near-term-tree by doing the following:

        run snaptrack to determine what files need brought uptodate
        mksb -back later-release later_mergesb
        workon -sb later_mergesb
	bmerge -jold-baselevel-label:new-baselevel-label file-name
        bci file-name
        bsubmit file-name

To determine what files need updated you can run snaptrack across the 3 snapshot files:
old-baselevel, new-baselevel, later-release snapshot.
That way, you could when you retarget later-release, do the mklinks again at that time.

Example:  

/usr/sde/ptos/link -->  ptliteos.bl2

later a retarget will be done to something like:
		/usr/sde/ptos/link -->  ptliteos.bl3

At that time mail will be sent out so all ptlite bugfixes wil get into
ptos by doing the following:

        run snaptrack to determine what files need brought uptodate

	mksb -back ptos ptos_mergesb
	workon -sb ptos_mergesb
	bmerge -jPTLITE_BL2:PTLITE_BL3 file-name
	bci file-name
	bsubmit file-name


Next mail message is snaptrack.
Anyone can run it, so you could try running it using
the snapshot fiiles in the osf pools  as well.

Tina



From:	RUST::"[email protected]"   11-APR-1995 10:06:35.85
To:	[email protected]
CC:	[email protected]
Subj:	ODE Admin question

We have two submit trees (shared sandboxes); one backed to the other.
One is for a near term release, and the other for a later release.

When someone does a bcreate and bsubmit to the near term tree, it does
not show up in the later tree, until a mklinks is done in the
later tree.  Is this the case with your trees also?

-Chip Dancy