Conference smurf::buildhelp

1269.0. "Re: Is this an ODE bug ? Unlock/Outdate information..." by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Feb 14 1995 20:51

Date Of Receipt: 	13-FEB-1995 15:28:15.13
From: 	SMURF::ALPHA::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	katz@DEC:.zko.alpha
CC: 	odehelp@DEC:.zko.alpha
Subj: 	Re:  Is this an ODE bug ?  Unlock/Outdate information...

Charlie, there are some misunderstandings here about what some switches
do.  Please don't recommend these steps, as it can really hose someone.
Can you post this mail as a follow-up in the support conference?

If you check out a file you shouldn't have, you need to unlock and
outdate the file, as follows. 

		bcs -u -o <file>

If you've done the check-in, then just outdate it:

		bcs -o <file>

This is not what you did.  Here's  a run-down on what you did:

		bcs -unlock <file>

does not unlock a file (<file> is ignored here) - it unlocks your
sandbox to allow multiple users to use it (an administrative thing
rarely useful for private sandboxes; it's used in submit sandboxes).

What you wanted to do was to unlock the file.  This command:

		bcs -u <file>

does unlock the file - but you will still have it checked out.  I guess
this is what you thought you were doing.  This may be useful in
isolation if you do bco/edit/bci/bco/edit and then want to revert to
the 1st checked in version - then just do bcs -u.  See below on how to
remove it altogether in your situation.

Editing the .BCSset-yourname_and_patch file in fact makes the -all switch
not know about the file, BUT YOU STILL HAVE IT CHECKED OUT.  If you at
some later time, backed by anything, do a bco on this file (from the
same sandbox) you'll get your old version, since the RCS branch by that
name is still around, not the version from the backingtree.

To remove your private branch after unlocking the file, this branch,
you need to "outdate" the file:

		bcs -o <file>

Do both unlock and outdate (the usual case), i.e.  to undo the bco of a
file as if you hadn't checked it out before, do the following (note it
will also rm the file from your sandbox):

		bcs -u -o <file>

You should still do this for the file(s) you removed from the .BCSset file.

-josh



> From katz@decvax.dec.com  Mon Feb 13 10:14:54 1995
> Delivery-Date: Mon, 13 Feb 95 10:14:57 -0500
> To: odehelp
> Subject: Is this an ODE bug ? 
> Date: Mon, 13 Feb 95 10:04:13 -0500
> 
> I've entered this in a notes conference for the support group. It
> saved me from annoying delays, but I would like you look into it
> as it may be wrong to have to do this, or might cause some other
> problems, thanks:
> 
> If you've accidentally checked out an unnecessary file you may
> need to remember this.
> If I remember correctly the bsubmit complains because if finds
> a problem with the file that hasn't changed at all, and it
> aborts.
> So the first remedial step I tried was 'bcs -unlock foo.c'
> This reported apparent success:
> 	rm: removing ./.BCSlock
> However, a bstat -all still shows the file (and the bsubmit will
> still try to include it too).
> 
> I have found that there is also a .BCSset-yourname_and_patch file
> in the src directory. I edited this file and deleted the reference
> to the unnecessary file. And the bsubmit went through.
> 
> Should this be necessary ? I've asked the ODE folks to look into
> it. But in the meantime, you can complete your bsubmit if you
> follow my workaround.