Conference smurf::buildhelp

182.0. "from dutile, Re: fwd: X pool inconsistencies, re: check_out_config question" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Mon Jun 28 1993 16:32

Date Of Receipt: 	28-JUN-1993 14:42:18.20
From: 	WASTED::jmf "Joshua M. Friedman ULTRIX SDE  28-Jun-1993 1442"
To: 	ws@wasted:zko.dec
CC: 	odehelp@wasted:zko.dec, grass@wasted:zko.dec, tresvik@wasted:zko.dec,
	afd@wasted:zko.dec, tappan@wasted:zko.dec, meyer@wasted:zko.dec,
	alphapc@wasted:zko.dec, bossec@wasted:zko.dec
Subj: 	from dutile, Re: fwd: X pool inconsistencies, re: check_out_config  question

------- Forwarded Message

Return-Path: [email protected]
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA29566; Mon, 28 Jun 1993 14:03:19 -0400
Message-Id: <[email protected]>
To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>
Cc: [email protected]
Subject: Re: fwd: X pool inconsistencies, re: check_out_config question 
In-Reply-To: Your message of "Mon, 28 Jun 93 13:37:29."
             <[email protected]> 
Date: Mon, 28 Jun 93 14:03:19 -0400
From: "By the time you make ends meet, they move the ends." <[email protected]>
X-Mts: smtp


Josh,
	Couldn't someone give the X folks a shell
script (in .cshrc for ex.) that redefines "workon"
to run through another workon script that checks
for .nightly, and redefines "bco" to "bco -r*x* (the
non-nightly version).  then the ones who really want this
"feature" can have it, and the rest of us will just
slog through the existing, known process ... ;-)....
	that way, it only affects the X folks using the
tools in a diff. manner, and those new to the X area will
be either (1) educated that this methodology exists, or
(2) deal with the merges.
	This sounds like a very bad way to solve merge
problems that the X folks seem more endeared to than other
groups (?).  I ditto your sentiments that more people beyond
the tightly nit (original) 5 require the std. processes to be
used, not this other "methodology".

/don

ps -- pls. feel free to pass along to those who should get
	this reply.  looking at your cc:, i didn't know
	the best list of folks.

=========================================================

To: alphapc, bossec
Cc: ws, odehelp, grass, tresvik, afd, tappan, meyer
Subject: fwd: X pool inconsistencies, re: check_out_config question  
Date: Mon, 28 Jun 93 13:37:29 +28716
From: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>

Alpha-PC and Security groups, fyi, I know that you are or will be
working with the "X" pool some, and thought you should be aware of the
following, and have a chance to input, as part of the development team.

Attached are 6 pieces of mail debating the following issue: in all the
x nightly pools, the x developers have had us structure the rc_files
such that when you're backed by nightly, a bco doesn't give you the
version from nightly, but from the submit tree, which may be more
recent, and therefore inconsistent with the backing tree, but it
reduces the need to do extra merges prior to submitting.

You should know about this structure, and if you have any arguments you
feel strongly about, please feel free to respond to the group...

Thanks...
	
	-josh






------- End of Forwarded Message

Date Of Receipt: 	28-JUN-1993 14:53:33.01
From: 	MINSRV::"[email protected]" "Michael D. Fairbrother UEG"
To: 	"Joshua M. Friedman, OSF/UNIX SDE 381-1548" <[email protected]>
CC: 	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected]
Subj: 	Re: from dutile, Re: fwd: X pool inconsistencies, re: check_out_config  question

Take a look at the bottom of ~mdf/.envfile for an example of how 
I use ksh to set given variables while entering a workon.

Note, that the ~mdf/.envfile gets run after the rc_files are parsed.

Date Of Receipt: 	28-JUN-1993 15:20:16.76
From: 	WASTED::fran "Fran Fadden USG  28-Jun-1993 1520"
To: 	"Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@wasted:zko.dec>
CC: 	alphapc@wasted:zko.dec, bossec@wasted:zko.dec, ws@wasted:zko.dec,
	odehelp@wasted:zko.dec, grass@wasted:zko.dec, tresvik@wasted:zko.dec,
	afd@wasted:zko.dec, tappan@wasted:zko.dec, meyer@wasted:zko.dec
Subj: 	Re: fwd: X pool inconsistencies, re: check_out_config question

I think the X pool way of working is, if not "more correct", at least
less likley to cause lost "fixes".  As an alternative to a README file
that may either not be read at the right time, or may not be updated as
frequently as necessary, I would like to make a proposal for additional
bco functionality:

regardless of which version bco is configured to give you in "your"
pool, have it look also at an "alternate" version.  If the versions are
different then a warning should be printed so that the developer can
verify that either a) this is the X pool, and the copy checked out is
consistant with the tree as necessary, or b) this is the base pool, and
the copy checked out is not wiping out valuable fixes.

I could be wrong, but it doesn't seen too hard to have these "magic"
strings:

AGXMINOR;AGXMAINT_BL4;X11;include /usr/sde/osf1/build/agxminor.nightly/CONFIG
AGOSMINOR_NIGHTLY;AGOSMAINT_BL4;alpha_bl012;<93/01/24,16:21:32

extended in some way to point to the alternate version too (or to
"configure" bco in some other way).

					Fran