Conference smurf::buildhelp

Date Of Receipt: 	23-MAR-1995 14:55:01.41
From: 	SMURF::WASTED::"ode@rust.zso.dec.com" "23-Mar-1995 1153"
To: 	buckley@eng.pko.dec.com
CC: 	odehelp@zk3.dec.com, jmf@zk3.dec.com, ode@rust.zso.dec.com
Subj: 	Re:  mksnapshot/corrupted SNAPSHOT files(Serious problem)

hi martin,

in the blog output that you included in your previous mail,
we noticed that the file shmstr.h_tga2 had a comment leader set to BIN.
files with the comment leader BIN are treated as binary files.  the comment
leader of a file can be changed by anyone through the bcs -c command.

if a file is a binary file as denoted by the comment leader BIN,
the log message for that submit is not included in the file but is kept
with the rcs file for history.  binary files are also not merged and new
submissions overwrite the previous version.  if for some reason a merge
situation happens, only 2 choices are available to the user and those are
1.  take my work and overwrite what's in the submit tree, or
2.  keep the file in the submit tree and do not submit my work.

if the person took the second option, you will have a file with
a new revision with seemingly old context.

what is misleading, which also through us for a loop is that the file
has an existing history revision area in the header of the file.

so someone, sometime, changed the comment leader of the file to BIN
which resulted in a different but correct behaviour.

jo


--------
#  HERE THE BLOG SHOWS THAT VERSION 1.1.2.4 is in the rcs file
jasper:devbld:x11> blog !$
blog ./server/ddx/dec/ffb/shmstr.h_tga2

[ ./server/ddx/dec/ffb/shmstr.h_tga2 ]

RCS file: ./server/ddx/dec/ffb/shmstr.h_tga2,v
Working file: shmstr.h_tga2
head: 1.1
branch:
locks: strict
access list:
symbolic names:
        v26_nt: 1.1.2.2
        TGA2HWSET: 1.1.4
        tga2: 1.1.2.3
        v26_ssb: 1.1.2.2
        V25_SSB_NT: 1.1.2.2
        v25_ssb: 1.1.2.2
        PEX: 1.1.2
comment leader: "BIN"       <------------- indicates binary file
keyword substitution: o
total revisions: 7;     selected revisions: 1
description:
- ----------------------------
revision 1.1.2.4
date: 1995/03/17 21:48:37;  author: Charlotte_Richardson;  state: Exp;  lines: +
1 -1
        Add pixel crock to work around software model bug
=============================================================================

Date Of Receipt: 	23-MAR-1995 15:10:09.18
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	buckley@eng.pko.dec.com, odehelp@zk3.dec.com
CC: 	jmf@zk3.dec.com
Subj: 	Re:  mksnapshot/corrupted SNAPSHOT files(Serious problem)

Martin, in the case that you listed, there's a subtle thing going on.
The file looks like it has active history, but the comment leader is
set to "BIN" and not to " * ".  Setting to BIN means the file is
handled like a Binary, and no rcs-keyword expansion is done at all,
and so $Header, $Log etc are really "static".  If you 

	bcs -c" * " shmstr.h_tga2
	bco -u shmstr.h_tga2

You'll find, I believe, that 1.1.2.4 will appear.  This file does
not have a standard extension found in your BCSHEADERS directory
(i.e. one of .c, .h, etc) and so bcreate sets the type to binary
by default - via setting the comment leader to BIN.

Hopefully, this describes most of the cases you have, and they can
be fixed by just setting the comment leader and checking the file
out again in the submit tree.  One could do the bcs -c and a new
bco/bci/bsubmit with the comment, fixing the header.  Any user is
able to do the bcs -c; it does not require admin.

By the way, the ODE development group, with mail interface decwet::ode,
is part of this odehelp distribution.

-josh

--------
To: odehelp@zk3.dec.com
Cc: jmf@zk3.dec.com
Subject: mksnapshot/corrupted SNAPSHOT files(Serious problem)
Date: Thu, 23 Mar 95 12:13:21 -0500
From: buckley@eng.pko.dec.com
X-Mts: smtp


I think I need to talk to someone in the ode development group.  Recently
you have mentioned that a couple of my messages concerning problems with 
ode were being forwarded to the west coast.

Well, I think I should actually contact ode development about my current
problems.


mksnapshot shows that our mainline pool has a number of problems.  Most seem
easy to solve.  A few are more serious.


In particular mksnapshot is stating that the submit tree has files that 
contain the wrong(older) contents.  
	bsubmit.log shows the checkin on a new version.  
	The comments in the file in the submit tree show that it is missing
	  this submission.
	blog shows that the rcs file contains the version that was submitted.
	bco -u file  states that it has taken the "correct" version out but
	  the file contains the wrong contents(it is old)
	bco -rv -u file states that it has taken the "correct" version out but
	  the file contains the wrong contents(it is old)


Here is the data:

SNAPSHOT:
./server/ddx/dec/ffb/shmstr.h_tga2,v    1.1.2.4

bsubmit.log:

  Submitted by Charlotte_Richardson; User name: clr; Node name: ddxrsl.eng.pko.d
ec.com
  ....
./server/ddx/dec/ffb/shmstr.h_tga2,v       1.1.2.4

 Detailed description:

[ ./server/ddx/dec/ffb/shmstr.h_tga2 ]
	Add pixel crock to work around software model bug



./server/ddx/dec/ffb/shmstr.h_tga2:

/*
 * @DEC_COPYRIGHT@
 */
/*
 * HISTORY
 * $Log:        shmstr.h,v $
 * Revision 1.2.2.2  92/06/11  12:17:45  Jim_Ludwig
 *      64-bit changes
 *      [92/06/10  11:42:05  Jim_Ludwig]
 *
 * Revision 1.2  91/12/15  12:42:16  devrcs
 *      Initial load of project
 *
 * $EndLog$
 */

bco -r1.1.2.4 -u ./server/ddx/dec/ffb/shmstr.h_tga2

[ ./server/ddx/dec/ffb/shmstr.h_tga2 ]
[ ./server/ddx/dec/ffb/shmstr.h_tga2 Rev 1.1.2.4 checked out unlocked ]
jasper:devbld:x11> !more
more ./server/ddx/dec/ffb/shmstr.h_tga2
/*
 * @DEC_COPYRIGHT@
 */
/*
 * HISTORY
 * $Log:        shmstr.h,v $
 * Revision 1.2.2.2  92/06/11  12:17:45  Jim_Ludwig
 *      64-bit changes
 *      [92/06/10  11:42:05  Jim_Ludwig]
 *
 * Revision 1.2  91/12/15  12:42:16  devrcs
 *      Initial load of project
 *
 * $EndLog$

#  HERE THE BLOG SHOWS THAT VERSION 1.1.2.4 is in the rcs file
jasper:devbld:x11> blog !$
blog ./server/ddx/dec/ffb/shmstr.h_tga2

[ ./server/ddx/dec/ffb/shmstr.h_tga2 ]

RCS file: ./server/ddx/dec/ffb/shmstr.h_tga2,v
Working file: shmstr.h_tga2
head: 1.1
branch:
locks: strict
access list:
symbolic names:
	v26_nt: 1.1.2.2
	TGA2HWSET: 1.1.4
	tga2: 1.1.2.3
	v26_ssb: 1.1.2.2
	V25_SSB_NT: 1.1.2.2
	v25_ssb: 1.1.2.2
	PEX: 1.1.2
comment leader: "BIN"
keyword substitution: o
total revisions: 7;     selected revisions: 1
description:
----------------------------
revision 1.1.2.4
date: 1995/03/17 21:48:37;  author: Charlotte_Richardson;  state: Exp;  lines: +
1 -1
	Add pixel crock to work around software model bug
=============================================================================

There seem to be a large number of files that are in a similar situation.


Obviously, this is quite serious and I am under a log of pressure to correct
all of these problems.

There is also the question of what is going wrong and how I can make sure that
these problems do not happen again in the future.




thanks
  Martin

Date Of Receipt: 	23-MAR-1995 15:10:41.68
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	buckley@eng.pko.dec.com, ode@rust.zso.dec.com
CC: 	jmf@zk3.dec.com, odehelp@zk3.dec.com
Subj: 	Re:  mksnapshot/corrupted SNAPSHOT files(Serious problem)

Oh - thanks Jo - I just saw your response, pretty much saying the
same thing as I just did....		-josh

Date Of Receipt: 	23-MAR-1995 15:58:09.79
From: 	SMURF::WASTED::"buckley@Eng.PKO.DEC.Com" "23-Mar-1995 1556"
To: 	ode@rust.zso.dec.com
CC: 	buckley@eng.pko.dec.com, odehelp@zk3.dec.com, jmf@zk3.dec.com
Subj: 	Re: mksnapshot/corrupted SNAPSHOT files(Serious problem)

Thanks for the response it does clear up the confusion about this file.


A question,  mksnapshot generated a mksnapshot.log file that contained
the following:


The following differences were found between the submit tree
and the New SNAPSHOT file:
./extensions/contrib/mwm_overlay/Mwm is Revision1.1.4.5 vs 1.1.2.2
./extensions/contrib/mwm_overlay/Mwm_bw is Revision1.1.4.5 vs 1.1.2.2
./extensions/contrib/mwm_overlay/Mwm_gray is Revision1.1.4.5 vs 1.1.2.2
./extensions/server/lgi/lib/lgiHw.def is Revision1.1.3.2 vs 1.1.2.3
./extensions/server/lgi/lib/lgiSw.def is Revision1.1.3.2 vs 1.1.2.3
./kit/O3D210.k is Revision1.1.2.2 vs 1.1.2.5
./server/Makefile.tga2 is Revision1.2.29.2 vs 1.1.2.4
./server/ddx/dec/ffb/Makefile.ref is Revision1.1.2.10 vs 1.1.2.3
./server/ddx/dec/ffb/XShm.c_tga2 is SNAPSHOTSNAPSHOT1 vs 1.1.2.4
./server/ddx/dec/ffb/XShm.h_tga2 is SNAPSHOTSNAPSHOT1 vs 1.1.2.4
./server/ddx/dec/ffb/shm.c_tga2 is SNAPSHOTSNAPSHOT1 vs 1.1.2.4
./server/ddx/dec/ffb/shmstr.h_tga2 is SNAPSHOTSNAPSHOT1 vs 1.1.2.4


This is whay I was looking at these files!  

Why is mksnapshot concerned about these files.  Should I ignore this section
of the mksnapshot.log if the files have a comment leader of "BIN"


On a related note, our builds are failing because 1 file does not end
up in the backing tree.  It turns out that this file is "in use"

jasper:devbld:x11> blog ./extensions/server/lgi/src/render/pvg/_Naccum.h

[ ./extensions/server/lgi/src/render/pvg/_Naccum.h ]
stat error: RCS file ./extensions/server/lgi/src/render/pvg/_Naccum.h,v is in us
e
stat error: RCS file ./extensions/server/lgi/src/render/pvg/_Naccum.h,v is in us
e

RCS file: ./extensions/server/lgi/src/render/pvg/_Naccum.h,v


I found the file rcstree//extensions/server/lgi/src/render/pvg/,_Naccum.h,


Three questions:
	1) What is the proper way for one to  make a file not "in use"?
	2) What is the ,file,;is it related to being "in use"?
	3) Can I just delete this file to solve the problem?


Thanks
  Martin Buckley

Date Of Receipt: 	23-MAR-1995 16:39:39.06
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	buckley@eng.pko.dec.com
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: mksnapshot/corrupted SNAPSHOT files(Serious problem)

Martin, I'm interested in what Jo from DECwest (she's answering ode
mail this week) has to say about your mksnapshot question.

Regarding the ,file, file - yes this is rcs's locking mechanism to allow
only one rcs command to work on a file at a time.  This could be left
behind if the system goes down during an rcs write operation, or if
some odd error happens that isn't trapped properly.  If the file's not
a current date/time, you can just remove it.  The date/time  may be
a clue to you as to what may have been the source of the problem.

-josh

Date Of Receipt: 	23-MAR-1995 20:04:10.68
From: 	SMURF::ALPHA::"ode@rust.zso.dec.com" "23-Mar-1995 1703"
To: 	buckley@eng.pko.dec.com
CC: 	odehelp@zk3.dec.com
Subj: 	Re:  mksnapshot/corrupted SNAPSHOT files(Serious problem)

hi martin,

verify that all the files listed under the heading 

>> The following differences were found between the submit tree
>> and the New SNAPSHOT file:

are binary files with old header sections in them as illustrated
by shmstr.h_tga2

mksnapshot verifies the version that is has for the file, is the
same as the most recent version logged in the header section of the
file.  this would normally signal a successful submit but for some reason
the SNAPSHOT file in the submit tree was not properly updated.

in your case the binary files that has old header sections in them
is causing mksnapshot to flag the true file revision with the old file
revision found in the file.  binary files normally do not have header files and
are therefore not flagged as a difference.

you can ignore the message or to clean up things, i would check out all
the binary files and remove the header sections from them.  hopefully
you'll never get files under this heading again.

it seems that the binary files were at one point non-binary.  do you know
the circumstances as to how to were turned into BIN files?

jo

Date Of Receipt: 	23-MAR-1995 20:42:14.23
From: 	SMURF::ALPHA::"buckley@Eng.PKO.DEC.Com" "23-Mar-1995 2041"
To: 	ode@rust.zso.dec.com
CC: 	odehelp@zk3.dec.com
Subj: 	Re: mksnapshot/corrupted SNAPSHOT files(Serious problem)

I have no idea why they are binary.  I could assume that when the files were
created/loaded into ode, they were not recognized to be c files and the
leader stayed binary.  Something that programmers could easily overlook.


On another note,  I am setting up an submit tree for x11r6 and have set up
a second rcs tree, that, I hope will contain(mostly) the same set of files,
though they will be at different locations in the rcs tree.

My first attemp at this was to use symbolic links for directories.  When
I ran mksubmit, it ran but did not put any files in the created submit tree.

Then I created a real directory structure with symbolic links for the rcs
files.  After running mksubmit, again no files in the submit tree.

Finally, I used hardlinks and mksubmit did create a submit tree with files.

I read the rcs man pages, they state something to the effect that rcs
purposefully uses temporary files when updating files, and relates that
this breaks hardlinks but works with symlinks.

Should I be concerned that the fist time someone submits a change to rcs
that the links are broken, effectively only updating one of the rcs files?

If so, then how did the X group get around this problem?


thanks in advance,

Martin Buckley