| Date Of Receipt: 16-JAN-1996 14:27:24.00
From: SMURF::FLUME::"vandyck@zk3.dec.com" "Grant Van Dyck 16-Jan-1996 1424"
To: Bob Harris (USEG) <harris@zk3.dec.com>
CC: odehelp@zk3.dec.com
Subj: Re: RCS numbers changed from 1.1.21.2 to 1.1.22.2 - why?
Not strange at all really. This is the normal behavior. When you check out a
file, ODE creates a private branch for your work in RCS - in this case the
1.1.21 branch. The first file you get is 1.1.21.1. When you checked it in, it
became 1.1.21.2, the number in your srequest. If you were to bco and bci
again, it would become 1.1.21.3 and so on.
When you submit, your submitted file gets appended to the public branch and
your private branch gets outdated and goes away (unless you specifically tell
it not to). It just so happens that the public branch for v32supportos is
1.1.22. Whatever the highest rev on that branch is, is the active file for
the pool. Since it hadn't been submitted here before, your submission created
the public branch, and it got assigned the next number up - 1.1.22, and the
actual submitted file became 1.1.22.2. Is that clearer?
-Grant
| I have a strange problem that I can not explain.
|
| I did an srequest in the v32supportos.nightly pool against
|
| ftx_routines.c
|
| and was assigned the RCS number 1.1.21.2. This is clearly shown in the
| srequest bdiff's output.
|
| Later after getting approvals, I did the bsubmit.
|
| When I checked the .../v32supportos.nightly/output/usr/sys copy of
| ftx_routines.o after the nightly builds, the RCS number was 1.1.22.2.
|
| I went to the sources and checked the .c file and there are no
| additional change comments, and as far as I can see there are no new
| srequests against the file.
|
| Does anyone know what is going on?
|
| Bob Harris
|
| Date Of Receipt: 16-JAN-1996 14:31:41.58
From: SMURF::ALPHA::jmf "Joshua M. Friedman OSF/UNIX SDE 16-Jan-1996 1429"
To: Bob Harris (USEG) <harris@DEC:.zko.alpha>
CC: odehelp@DEC:.zko.alpha
Subj: Re: RCS numbers changed from 1.1.21.2 to 1.1.22.2 - why?
Bob, this is the correct behavior.
The ODE documentation explains that within ODE, when you do a bco of a
file, you are assigned a PRIVATE rcs "branch", on which your work is
saved everytime you do a bci, until you finally outdate your branch
(normally at the end of a bsubmit). This branch has both a number and
a name; 'blog' will show you these symbolic names/numbers.
When you do a bsubmit, your work is put on a PUBLIC rcs branch, called
the submit branch. This branch also has a number and a symbol. If the
file is new to the project (eg to ptos or v32supportos) then the submit
branch gets created when the first submit is done.
Your srequest shows your private branch information; once the submit is
done, that branch is deleted and is no longer accessible, and the changes
are put on the public branch, and the internal revs in the file header
are also changed to reflect the correct new numbers.
In this case:
private branch:
Robert_Harris_yoursandbox = 1.1.21 branch,
containing your private bci, 1.1.21.1, 1.1.21.2
public branch:
V32SUPPORTOS = 1.1.22 branch,
containing the public submit, 1.1.22.1, 1.1.22.2
(in both cases, the <branch>.1 revision is created to establish the
branch, and the <branch>.2 revision holds the first actual check-in)
Please see the ODE user's guide for more complete information.
-josh
--------
Date: Tue, 16 Jan 1996 13:59:58 -0500
From: Bob Harris (USEG) <harris>
Message-Id: <9601161859.AA11427@guru.zk3.dec.com>
To: odehelp
Subject: RCS numbers changed from 1.1.21.2 to 1.1.22.2 - why?
I have a strange problem that I can not explain.
I did an srequest in the v32supportos.nightly pool against
ftx_routines.c
and was assigned the RCS number 1.1.21.2. This is clearly shown in the
srequest bdiff's output.
Later after getting approvals, I did the bsubmit.
When I checked the .../v32supportos.nightly/output/usr/sys copy of
ftx_routines.o after the nightly builds, the RCS number was 1.1.22.2.
I went to the sources and checked the .c file and there are no
additional change comments, and as far as I can see there are no new
srequests against the file.
Does anyone know what is going on?
Bob Harris
|