| Date Of Receipt: 8-JUL-1993 12:43:09.79
From: WASTED::jmf "Joshua M. Friedman ULTRIX SDE 08-Jul-1993 1243"
To: brett@wasted:zko.dec
CC: [email protected], odehelp@wasted:zko.dec
Subj: Question on Sterling merge procedure.
Brett, this question is really for you...
Rich, note that until the next successful nightly build of sterling,
agosminor.nightly is in sync with maint bl4, not bl6. For this interim,
backing to the submit tree does make sense; the instability you refer
to is definitely true, but it is a small amount of change "underfoot",
and developers should in general be aware if their "area" is changing.
-josh
------- Forwarded Message
Return-Path: [email protected]
Received: by minsrv.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA26539; Thu, 8 Jul 1993 11:58:56 -0400
Received: by lars.unx.dec.com (5.65/MS-070792);
id AA25107; Thu, 8 Jul 1993 11:58:36 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: Question on Sterling merge procedure.
Date: Thu, 08 Jul 93 11:58:36 -0400
From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
<[email protected]>
X-Mts: smtp
I have just read the Sterling merge doc. I have noticed that the stated
procedure
is to use agosminor for code diffs and merging. However, they imply that when
testing their code merge that they should build using agosminor. I was told that
building against the submit tree is not advisable since the pool is updated
once an hour. That there is a potential for files to change right from under
you which could cause the build to fail.
What are your thoughts?
Rich
- ----------------------------------------------------------------
Rich Larsen, M/S: UNX TCP/IP: [email protected]
USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
Digital Equipment Corporation FAX: 908-577-6003
200 Route 9 North Voice: 908-577-6083
Manalapan, New Jersey 07726 DTN: 462
------- End of Forwarded Message
|
| Date Of Receipt: 8-JUL-1993 12:59:30.49
From: FLUME::"[email protected]" "Madeline Barcia-Asmus USG"
To: [email protected]
CC: [email protected], [email protected], [email protected]
Subj: Re: Question on Sterling merge procedure.
Rich,
Also, you might suggest to users, along with what Josh mentioned,
that if they have enough disk space , they could use mklinks -copy
of their obj area prior to test building. That might help.
Just a thought.
-Madeline
>>Brett, this question is really for you...
>>
>>Rich, note that until the next successful nightly build of sterling,
>>agosminor.nightly is in sync with maint bl4, not bl6. For this interim,
>>backing to the submit tree does make sense; the instability you refer
>>to is definitely true, but it is a small amount of change "underfoot",
>>and developers should in general be aware if their "area" is changing.
>>
>>-josh
>>
>>------- Forwarded Message
>>
>>Return-Path: [email protected]
>>Received: by minsrv.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
>> id AA26539; Thu, 8 Jul 1993 11:58:56 -0400
>>Received: by lars.unx.dec.com (5.65/MS-070792);
>> id AA25107; Thu, 8 Jul 1993 11:58:36 -0400
>>Message-Id: <[email protected]>
>>To: [email protected]
>>Subject: Question on Sterling merge procedure.
>>Date: Thu, 08 Jul 93 11:58:36 -0400
>>From: "Rich Larsen (908) 577-6083 DTN 462-6083 [email protected]"
>><[email protected]>
>>X-Mts: smtp
>>
>>
>>I have just read the Sterling merge doc. I have noticed that the stated
>>procedure
>>is to use agosminor for code diffs and merging. However, they imply that whe
n
>>testing their code merge that they should build using agosminor. I was told
that
>>building against the submit tree is not advisable since the pool is updated
>>once an hour. That there is a potential for files to change right from under
>>you which could cause the build to fail.
>>
>>What are your thoughts?
>>
>>
>>Rich
>>- ----------------------------------------------------------------
>>Rich Larsen, M/S: UNX TCP/IP: [email protected]
>>USSG/User Env. & Std. Group DECnet: UNXA::LARSEN
>>Digital Equipment Corporation FAX: 908-577-6003
>>200 Route 9 North Voice: 908-577-6083
>>Manalapan, New Jersey 07726 DTN: 462
>>
>>------- End of Forwarded Message
>>
>>
|
| Date Of Receipt: 8-JUL-1993 14:11:04.22
From: FLUME::jmcg "Jim McGinness"
To: [email protected], [email protected]
CC:
Subj: Re: Question on Sterling merge procedure.
Building against the submit tree is generally not advisable, both because
the system exporting the submit tree is also responsible for all ODE RCS
activity and because the submit tree is volatile.
During the merge, though, building against the submit tree is the only way
to check whether a newly merged file compiles correctly, and even then
it's not guaranteed correct because other merges may be pending on which
the component is dependent. The nightly tree is not re-backed yet (either
because it's the first day of the merge or because the build often fails
after the first day because only some of the merges were complete), so
none of the silent, non-conflict merges show up there.
-- jmcg
|