Conference smurf::buildhelp

2465.0. "QUESTION plus FYI: Small ODE notes toward finding the real revisions" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Aug 06 1996 20:34

Date Of Receipt: 	 6-AUG-1996 19:26:42.09
From: 	KAMLIA::kucherov "sergei kucherov  06-Aug-1996 1925"
To: 	jmf@DEC:.zko.kamlia
CC: 	kucherov@DEC:.zko.kamlia, odehelp@DEC:.zko.kamlia
Subj: 	QUESTION plus FYI: Small ODE notes toward finding the "real" revisions

I believe it would be a sweet feature if ODE could directly
answer the question:
	Given a pool and a file in the pool,
	what revision numbers in sequence constitute the bsubmit history
	of the file (since the beginning of time, through all pools that
	are "ancestors" of this pool)?

Most other config. mgt. systems I've used can answer the above question
directly and accurately. If by some miracle, ODE can answer my question,
then please let me know and I'll spread the good word.

- sergei


P.S. Could the answer be as simple as ignoring all "Initial Trunk Revision"
chunks? Nope, since my just bci'd version is in "blog -r" but I haven't
bsubmit'd it yet.

------- Forwarded Message

Return-Path: kucherov
Received: from localhost by kamlia.zk3.dec.com; 
(5.65v3.2/1.1.8.2/05Mar96-0145PM)
	id AA11930; Tue, 6 Aug 1996 19:12:43 -0400
Message-Id: <[email protected]>
To: kucherov
Cc: useg_fs, eugeneku, thomson
Subject: Partial NEVERMIND: Re: Small ODE note on finding the "real" revisions 
of a file 
In-Reply-To: Your message of "Tue, 06 Aug 96 18:50:17 EDT."
             <[email protected]> 
Date: Tue, 06 Aug 96 19:12:43 -0400
From: kucherov
X-Mts: smtp


I believe that all bsubmits are reflected in the "blog -r" output,
but there also seems to be non-bsubmitted versions
(ie. private branches) in the "blog -r" output.

Of course pool/logs/bsubmit.log contains the revision for each file
bsubmit'd to pool, but not to other pools further back in the ancestry.

It seems to be a non-trivial problem to derive exactly which revisions
are "valid" for a given file. "blog -r" seems to give a superset of
the solution. Each bsubmit.log gives part of the solution.
Intimate knowledge of how pools were merged gives part of the solution.

Someday, if and when I have a better answer (hopefully a tool)
I'll let you know. However, I suspect I'm asking a question that
the ODE model was not designed to answer succinctly.

	Partly there,
	sergei

------- End of Forwarded Message

------------------------------------------------------------------------------

To: useg_fs
Cc: kucherov, eugeneku, thomson
Subject: Small ODE note on finding the "real" revisions of a file
Date: Tue, 06 Aug 96 18:50:17 -0400
From: kucherov
X-Mts: smtp


I'm pretty sure most all of you know this by now,
but anyway this note is for the record.

The revision header comments in an ODE file can not ever be depended on
to be complete. Sometimes a bsubmit (esp. when merging pools)
may result in many extra revision header comments or even in deleting
valid revision header comments. Also some files, such as
ptos/src/kernel/msfs/msfs/bs_public.h have no header comments at all.
I ran into several of these anomalies today.

In a sandbox, cd to the appropriate directory and do:
	blog -r FILE

This will give you the true revision history of FILE,
including all bsubmits (with comments) to pools in the FILE's history,
no matter how tangled. (Note: the ~kucherov/bin/grep_revs tool
needs to be improved to use the "blog -r" output rather
than depending on the header comments.)

	sergei