[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | USG buildhelp questions/answers |
|
| Moderator: | SMURF::FILTER |
|
| Created: | Mon Apr 26 1993 |
| Last Modified: | Mon Jan 20 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2763 |
| Total number of notes: | 5802 |
1580.0. "new ODE revert operation, Re: linking v32 and v32b cam_disk.c" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Jun 27 1995 16:18
Date Of Receipt: 27-JUN-1995 12:12:54.04
From: SMURF::WASTED::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: reimers@albets.zk3.dec.com
CC: brett@DEC:.zko.wasted, darrell@DEC:.zko.wasted, metsch@DEC:.zko.wasted,
mwarren@DEC:.zko.wasted, odehelp@DEC:.zko.wasted, snow@DEC:.zko.wasted,
tresvik@DEC:.zko.wasted, useg@DEC:.zko.wasted
Subj: new ODE 'revert' operation, Re: linking v32 and v32b cam_disk.c
Jan, this is a timely question! "Coming soon to a pool near you"
This feature will strengthen the benefits of support mainstreaming.
> ... Is there a way of linking them together
> again so that bsubmits in v3.2 find their way into v3.2b?
Yes, but not yet. Around early August we are upgrading our tools
environment to DECode-II V3.0, and this includes a feature that we
requested call "revert". This kind of submit allows a pool to no
longer have a different version from its parent, but to share it again.
From the man page:
revert - revert a shared sandbox file to the version found in
its the backing tree.
In your case, the file would be reverted in v3.2b - it would turn back
into a link and the appropriate rcs and logfile bookkeeping takes
place. This is a user operation; it does not require admin assistance,
as it has up until now.
Using this on a regular basis in the support environment will help
maximize the benefits of the pools backing to one another, i.e. the
"mainstreaming" proposal.
For now you need to do two submits, but just one bco/bci. First use
"bsubmit -noauto_out", then resb other_pool, and "bsubmit". You can
use the -form switch in srequest to log the same form in both pools.
-josh
----------
To: jmf@albets.zk3.dec.com
Subject: linking v32 and v32b cam_disk.c
Date: Tue, 27 Jun 95 10:52:39 -0400
From: reimers@albets.zk3.dec.com
X-Mts: smtp
Status: R
Josh,
cam_disk.c should be identical for v3.2 and v3.2b, but at some point along
the way, v3.2b had changed it. Is there a way of linking them together
again so that bsubmits in v3.2 find their way into v3.2b?
Jan Reimers
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1580.1 | Re: new ODE revert operation | AOSG::FILTER | Automatic Posting Software - mail to flume::puck | Wed Aug 16 1995 17:37 | 60 |
| Date Of Receipt: 16-AUG-1995 10:42:35.61
From: SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE 16-Aug-1995 1038"
To: reimers@albets.zk3.dec.com
CC: odehelp@DEC:.zko.flume, jmf@DEC:.zko.flume
Subj: Re: new ODE 'revert' operation
Jan, revert did what it's intended to do; it replace the file with a
link to what v32csupport's backed to via 'link' -- ptliteos.bl6, not v32b.
Please re-submit the file into v32csupportos (use your original defect#).
The revert (and undefunct) are both a form of submit, and should be
preceeded by a submit request and approval.
There needs to be some education on these new tools; I may disable them
in our environment for now.
Once we do have support pools backed by one another this will be a
very powerful tool to routinely do exactly what you tried to do.
-josh
> Hi Josh,
>
> Perhaps I didn't understand what this command does.
> I used it with unexpected results.
> Please help me figure this out before the build tonight.
>
> I had made changes to ./kernel/io/cam/qlogic/isp1020.c in v32bsupportos
> and v32csupportos, such that the files were identical except for the RCSID.
> So I figured I'd try the revert command to get v32csupportos to be linked
> back to v32bsupportos. From my sandbox resb'd to v32csupportos, I did:
>
> v32b_qlogic[20] revert isp1020.c
>
> [ removed label, V32CSUPPORTOS, from filename, ./kernel/io/cam/qlogic/isp1020.c
> . ]
> [ removed filename './kernel/io/cam/qlogic/isp1020.c', from submit tree 'v32csup
> portos' . ]
> [ relinking filename './kernel/io/cam/qlogic/isp1020.c' to the backing pool of ]
> [ the shared sandbox v32csupportos. ]
>
> *** The following file(s) have been reverted successfully,
> *** and their entries have been deleted from the SNAPSHOT file.
> './kernel/io/cam/qlogic/isp1020.c'
>
> Then I checked the file in v32csupportos and found that it had removed the
> changes I had bsubmitted into that support pool. :-(
>
> Jan Reimers
>
> P.S. I did this from my own sandbox. The 'revert' man pages talks about
> "shared" sandboxes. I don't really understand what a shared sandbox is.
> Is that a problem?
>
> P.P.S. I'm looking forward to the ODE training tomorrow. I probably should
> not have tried this command until after the training. ;-)
|