Conference smurf::buildhelp

Delivery-Date: Thu, 29 Apr 93 13:41:24 -0400
Return-Path: [email protected]
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA20844; Thu, 29 Apr 1993 13:41:10 -0400
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA28882; Thu, 29 Apr 1993 13:40:30 -0400
Date: Thu, 29 Apr 1993 13:40:28 -0400
Message-Id: <[email protected]>
From: [email protected] (Kim Peterson, DECwest Engineering)
To: "[email protected]"@LOCORE.ENET.dec.com
Cc: "[email protected]"@LOCORE.ENET.dec.com
Subject: RE: access the RCS branch

It sounds like you should do your submit from the alpha sandbox.
The simplest thing to do is to move your existing sandbox from your decstation 
3100 to the alpha.  There are equivalent instructions on moving sandboxes in the 
Silver Supplement (I think) and the ODE V2.0 Users Guide, section 3.11 (which 
should be available via bookreader).

After you move your sandbox, nuke your object and export directory trees
(from your sandbox src directory, rm -rf ../obj/alpha/* ../export/alpha/* )
(it would probably be faster to just refrain from copying these files to begin 
with)
since your build problems may be related to the make you built originally

All branches and revisions will be as before.
--Kim
===============================================================================
From:	LOCORE::"[email protected]"   29-APR-1993 10:16:44.85
To:	[email protected]
CC:	[email protected], [email protected]
Subj:	access the RCS branch

hi,

I had a sandbox on decstation 3100 backed against aosgmaint.

I successfully ran a build from ./usr/ccs/bin/make

I successfully did a bco, made code changes then did a bci.

I successfully ran a build from ./usr/ccs/bin/make again

Now for some reason, I cannot successfully run a build in
./usr/ccs/bin/make from my decstation 3100.

I created a completely new sandbox and still cannot successfully
run the build on my decstation 3100.

I have a submit request approval from the original decstation
3100 sandbox.

I do not want to do the submit because the cause of the build problem
is unknown.

I have created a new sandbox on an alpha box that builds fine.

The question is, "How do I access the RCS branch of the original
decstation 3100 sandbox on the alpha box sandbox so that I can
do the submit"?

Is this the best way to handle this problem?

Should I get a new submit approval for a new RCS branch?


Any Pointers or hints would be appreciated. 

John D. DTN 462-6078



    

Delivery-Date: Thu, 29 Apr 93 14:25:28 -0400
Return-Path: jmcg
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA22993; Thu, 29 Apr 1993 14:22:05 -0400
Date: Thu, 29 Apr 1993 14:22:05 -0400
From: jmcg (Jim McGinness)
To: [email protected], [email protected], [email protected]
Subject: Re:  access the RCS branch

Access to RCS revisions is independent of node or architecture.  You
should be able to "bco -u" the contents of your old sandbox into the
new...do a blog on the file to see the label string to use with the
-r flag.

	-- jmcg
    

Delivery-Date: Thu, 29 Apr 93 14:55:21 -0400
Return-Path: vandyck
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA24758; Thu, 29 Apr 1993 14:54:48 -0400
Received: by polaris; id AA01426; Thu, 29 Apr 93 14:54:00 -0400
Message-Id: <9304291854.AA01426@polaris>
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: access the RCS branch 
In-Reply-To: Your message of "Thu, 29 Apr 93 13:17:27 EDT."
             <[email protected]> 
Date: Thu, 29 Apr 93 14:53:59 EDT
From: Grant Van Dyck <vandyck>


| hi,
| 
| I had a sandbox on decstation 3100 backed against aosgmaint.
| 

| 
| I do not want to do the submit because the cause of the build problem
| is unknown.
| 
| I have created a new sandbox on an alpha box that builds fine.

That's all you need to know really. We don't ship or test cross-built
bits (and hopefully - soon, we won't be supporting cross builds at all.)

| 
| The question is, "How do I access the RCS branch of the original
| decstation 3100 sandbox on the alpha box sandbox so that I can
| do the submit"?
| 

In your new sandbox do a blog -r filename to find the revision or
symbolic name for your branch and bco -j"your_branch":SUBMIT_BRANCH filename.

This will create a merged version of the file ready to checkin and submit.
Look it over carefully for merge markers and any other discrepancies.

	-Grant

    

Delivery-Date: Thu, 29 Apr 93 17:45:37 -0400
Return-Path: decwet::peterson
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA02425; Thu, 29 Apr 1993 17:39:40 -0400
Date: Thu, 29 Apr 1993 17:39:38 -0400
From: decwet::peterson (Kim Peterson, DECwest Engineering)
To: FLUME::"[email protected]"
Cc: FLUME::"[email protected]", FLUME::"[email protected]"
Subject: Moving work from one sandbox to another with bco -j

This is being sent out to a wide mailing to correct errors in a previous 
mailing.

The use of bco -j is described in the ode V2.0 Users Guide, sect 4.7

You can use the following simple case to move files between sandboxes IF both 
sandboxes are backed to the same build (for instance, agosmaint.bl2).  If the 
sandboxes are not backed to the same build you need to do more work to find a 
common ancestor.

In the simple case where both sandboxes are backed to a common build,
find the full branch name of the sandbox revision that exists.  The branch name 
will be of the form <principal-name>_<set-name> or <login-name>_<set-name>
and can be found by looking through the labels listed by blog -h
Once the full branch name is found (for instance Kim_Peterson_foo), then do

bco -jKim_Peterson_foo.1:Kim_Peterson_foo <file-name>

The command uses as a common ancestor the revision the file was originally 
checked out against (Kim_Peterson_foo.1) and it uses it to merge the latest 
version in the sandbox (Kim_Peterson_foo) and the current revision in the 
backing build (which is the version that an ordinary bco would give you).

Unlike bmerge, bco -j does not detect merge conflicts, and so you must grep the 
resulting checked out file for conflict markers (<<<, ===, and >>>)

YOu would then use bmerge -r$NEW in the standard way to merge in the latest 
submitted revisions.
--Kim