Conference smurf::buildhelp

2423.0. "Re: I think I just hosed a ptaos file by accident" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Wed Jul 17 1996 21:27

Date Of Receipt: 	17-JUL-1996 17:02:41.19
From: 	FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	tpb@DEC:.zko.flume
CC: 	mansour@zso.dec.com, odehelp@DEC:.zko.flume, pta_pt@DEC:.zko.flume,
	tea@DEC:.zko.flume
Subj: 	Re: I think I just hosed a ptaos file by accident

(Tina & Rima, I've copied you as an FYI - our first user "oops" with
revert since we upgraded to ode 3.1 and put it back in the user's path)


Tom, the revert command worked absolutely correctly.  It modified the
same file in the same tree, consulting the same ACL list and updating
the same logfile that would have been changed had you typed "bsubmit".

Remember that 'revert' is a _user_ level command, not an administrative
command.  Users only work in their normal sandboxes.  As far as ODE was
concerned, you were in a user sandbox backed by a backingtree created
from the ptaos shared sandbox. 

Just as submits, when backed to ptaos.bl3, are directed to the submit
tree, ptaos, so are reverts and undefuncts only applied to the submit
tree.  Baselevels are read-only entities, "snapshots" or "milestones"
of the actual pool.

In retrospect, you can see that the WARNING did not list your shared
sandbox (tadpole) at all; this should have been a clue:
    '/usr/sde/osf1/build/ptaos/src/./kernel/bsd/uipc_domain.c'
    (file in shared sandbox)

Unfortunately for terminology, all these pools are shared sandboxes;
there's nothing special about tadpole vs ptaos in that regard.

Is there anything else the user-interface could have provided to prevent
or make less likely this accident from your perspective?    Improvements
are always welcome.  If you do have anything to suggest along these lines,
that's the problem report you should file.

For example, this from your mail below is a worthwhile suggestion; I'll
leave it to you to file this:

> ...  It also is
> sensitive to the #pragma ident lines in source files, telling you there is
> a conflict if the #pragma ident lines don't match, which they won't; maybe
> it should have a -km option like bmerge?
>
> Tom


Thanks...  (fyi, I've cc'd the 'revert' developers for this)

-josh

-----------------
From tpb  Wed Jul 17 13:58:30 1996
Delivery-Date: Wed, 17 Jul 96 13:58:32 -0400
To: vandyck, jmf
Subject: I think I just hosed a ptaos file by accident
Date: Wed, 17 Jul 96 13:58:13 -0400
From: "Dr. Tom Blinn, 603-881-0646" <tpb>
X-Mts: smtp

I was trying to revert a file out of my tadpole sandbox, which is backed by
the ptaos.bl3 tree, but I was in a workon to the shared sandbox (not to one
of the sandboxes backed by the shared sandbox), and when I told it to revert
the file, it looks like it replaced the ptaos file with a link into the
ptaos backing tree.

Here's the screen log of what happened:

csh[21]> revert kernel/bsd/uipc_domain.c 
>> WARNING in revert:
>> Differences are found.
 
The body of the following 2 files does not match:
'/usr/sde/osf1/build/ptaos/link/src/./kernel/bsd/uipc_domain.c' (file to revert to) 
'/usr/sde/osf1/build/ptaos/src/./kernel/bsd/uipc_domain.c' (file in shared sandbox)
 
Compare the differences between the 2 files and verify you do want to
revert.

Continue with revert? [Y]es, [N]o: [N] y

[ removed label, PTAOS, from filename, ./kernel/bsd/uipc_domain.c . ]
[ removed filename './kernel/bsd/uipc_domain.c', from submit tree 'ptaos' .  ]
[ relinking filename './kernel/bsd/uipc_domain.c' to the backing pool of ]
[ the shared sandbox ptaos. ]

*** The following file(s) have been reverted successfully,
*** and their entries have been deleted from the SNAPSHOT file.
         './kernel/bsd/uipc_domain.c' 
csh[22]> ls -l kernel/bsd/uipc_domain.c 
-r--r--r--   1 tpb      staff      11568 Jun  7 19:03 kernel/bsd/uipc_domain.c
csh[24]> ls -l ../link/src/kernel/bsd/uipc_domain.c 
-r--r--r--   1 devbld   staff      11994 Jun 27 16:25 ../link/src/kernel/bsd/uipc_domain.c
csh[25]> ls -l /usr/sde/osf1/build/ptaos/src/kernel/bsd/uipc_domain.c 
lrwxr-xr-x   1 devbld   staff         61 Jul 17 13:51 /usr/sde/osf1/build/ptaos/src/kernel/bsd/uipc_domain.c ->
/usr/sde/osf1/build/ptaos/link/src/./kernel/bsd/uipc_domain.c
csh[26]> 

I doubt the file had changed between ptaos.bl3 and the current ptaos, but it
needs to be restored.

I apologize for this ham-fingered screw up.  (Looks like revert isn't quite
as simple to use as I would have thought.)

Tom

---------------
From tpb  Wed Jul 17 14:33:21 1996
Delivery-Date: Wed, 17 Jul 96 14:33:22 -0400
To: "Grant Van Dyck" <vandyck@lynx.zk3.dec.com>
Cc: pta_pt, jmf
Subject: Re: I think I just hosed a ptaos file by accident 
In-Reply-To: Your message of "Wed, 17 Jul 96 14:10:02 EDT."
             <9607171810.AA18534@lynx.zk3.dec.com> 
Date: Wed, 17 Jul 96 14:33:01 -0400
From: "Dr. Tom Blinn, 603-881-0646" <tpb>
X-Mts: smtp


> Yes, you certainly did. A DANGEROUS command to be sure. That's why we don't
> advertise it.

You know, I don't think the command actually works as advertised -- or maybe
I am missing something.  Or maybe the ptaos.bl3 rc_files are set up so that
I wound up hosing PTAOS instead of PTAOS_BL3.

The reference page says:

DESCRIPTION
    The revert command  allows the user to revert specific shared
    sandbox file(s), to the version found in the backing tree
    of the shared sandbox.

    revert requires the user to be in a sandbox backed to a shared sandbox.

I was in a sandbox backed by ptaos.bl3.  I suppose that to the ode tools the
ptaos.bl3 backing tree looks like a shared sandbox.  So I would have thought
it would try to revert the file in the ptaos.bl3 backing tree to the one in
ptaos (which I assume is the backing tree for ptaos.bl3).  Instead, what it
seems to have done was gone into the PTAOS tree and reverted the file there.

Is that a bug or a feature?  Either way, I screwed up by being in the wrong
place when I issued the command, but I am surprised it wiped out the file in
the active submit tree instead of trying to wipe out the file in ptaos.bl3;
in fact, if it had tried to operate on ptaos.bl3 (as advertised), I doubt it
would have succeeded, since it claims that:

                            ... If access control lists (ACL) are found
    in the shared sandbox logs directory, then the principal name of the
    user needs to be specified in that list, in order to excecute revert.

and I doubt that I am in an ACL for submits into ptaos.bl3 (which should be
locked at this point, right?).

So maybe I should be filing a QAR against the revert command.  (It also is
sensitive to the #pragma ident lines in source files, telling you there is
a conflict if the #pragma ident lines don't match, which they won't; maybe
it should have a -km option like bmerge?)

Tom