Conference smurf::buildhelp

2338.0. "ODE 3.1 Upgrade Planned soon in ZK; revert/merge history choices" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Tue Jun 11 1996 19:47

Date Of Receipt: 	11-JUN-1996 18:18:04.20
From: 	FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  11-Jun-1996 1817"
To: 	jproj@DEC:.zko.flume, reynolds@DEC:.zko.flume, cascio@DEC:.zko.flume,
	morse@DEC:.zko.flume
CC: 	odehelp@DEC:.zko.flume, tresvik@DEC:.zko.flume, decwet::snow,
	decwet::anderson
Subj: 	ODE 3.1 Upgrade Planned soon in ZK; revert/merge history choices

Digital UNIX development/support/doc/qa managers,

I am now evaluating the upgrade to DECode-II V3.1 for all of ZK3, which
is primarily maintenance on V3.0, plus some functionality.   I am
staging this in a private environment, and would like to do the upgrade
in the next week to two weeks (by the end of the month).  The
integration of the new tools will only require locking the pools for an
hour for the upgrade.

Please let me know your feedback, and if there are any particularly
good or bad times for the upgrade.


This is a minor upgrade, without site compatibility issues.  Each
Digital UNIX site is free to upgrade when they want to; some have
already done so.

This upgrade would be done according to the ODE Tools routine
maintenance upgrade plan, /usr/specs/release_bld/plans/odepatches.nr
or .ps, or on the web under http://nsa.zk3.dec.com/rengweb/specs/ .

There are two features which we asked for which have been implemented,
and I'd like to recommend we "turn on":

  - One is the use of revert & undefunct; we had reservations about the
    initial implementation of revert, and these have been addressed
    (see below).  I would recommend we NOT use the "strict" match, but
    the default mode which allows the developer to make an informed
    choice.  When we implement this, I would propose we add something
    to all the submit request forms to provide a place for users to
    declare that they are reverting or undefuncting, and provide user
    education.   Attached is mail from last September regarding this
    issue and with proposed text.

  - The other feature is the merge history feature in which that bmerge
    & bsubmit retain a history of the merge work that has been done
    to allow better tracking.  There was a problem in the first
    implementation (its comment characters posed a problem in Pascal files)
    and so we turned it off at the project level.  This problem has been 
    corrected, so I'd like to recommend we turn the feature back on. 

Below are the release note entries regarding these two issues, and below
that is attached mail regarding the revert history.

Thank you very much...			-josh


----------

Excerpted from the release notes; for the full document see
  http://www.zso.dec.com/ode/ODE-release_notes.html


5. Problems Resolved Since the Last Release

Many problems were fixed in this release. Problems of particular
interest to the user are highlighted below.

5.1 Merge history info no longer has "{" and "}"

The history entry for recording merge information no longer has the "
{** " " **}" syntax.  Instead the following syntax is used " ** "
& " ** ". For example:


* ** Merge Information **
* ** Command used: bmerge -jOLD:NEW **
* ** Ancestor revision: 1.1.2.2 **
* ** Merge revision: 1.1.2.8 **
* ** End **
* User's change comments appear here

Some projects which have pascal files had disabled this feature because
the pascal files would not compile with the "{" and "}" inserted in the
history. This feature can be enabled by removing the following rc_files
variable:

save_ancestor_info FALSE. 


5.2 revert tool now warns

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.
This command now has more restrictions to prevent accidentally
reverting a file.

Revert has 2 modes. The "lazy" and "strict" mode.Given a shared sandbox
and the shared sandboxes backing tree for a given file where the data
does not match between the files in the two trees, the following will
happen in revert:

 revert's "lazy" mode (default)
                          revert's "strict" mode 
 gives warning and prompts to
 continue
                          gives error and exits


The default is to allow reverts if the shared sandbox and backing tree
file's data do not match. A project can change the mode to not allow
the revert by adding a rc_file variable:

revert_match strict 

The recommended mode is the default "lazy" mode. Below is an example:

revert hello.c
>> WARNING in revert:
>> Differences are found.

The body of the following 2 files does not match:
'/usr/sde/tutorial/build/sharedsbox/link/src/./test/tina/hello.c' (file to 
revert to) 
'/usr/sde/tutorial/build/sharedsbox/src/./test/tina/hello.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] 


(other items in this section, fyi, without their text:)

5.3 bsubmit -l (relink on submitting)
5.4 commands have new flag -f (bco,bci, bcs,bmerge,undefunct)
5.5 bmerge -config_update
5.6 odediff now GNU diff 2.7
5.7 bcs -u -o -auto_out



------- Forwarded Message

To: jproj, bib, altan, metsch
Cc: reng, tresvik
Subject: submit form proposal for revert/undefunct operations
Date: Wed, 06 Sep 95 13:43:56 -0400
From: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>

Release project leaders,

In ODE V3.0 there are two new powerful commands (which we have asked for)
which provide two new ways to effectively do submits.  I propose that all
release streams add the following to their submit request form(s) to 
provide a place for users to srequest intentions to revert or undefunct.

In the form, all the lines starting with _|_ get filtered out by srequest.

(short commercial:)
You can also modify your existing forms to have as much filtered out with
this comment leader as you want (please have it reviewed by Sean Davidson
first, as there are some special lines with directives like bstat or bdiff
or inventory files, if you decide to take advantage of this filter feature.)
You can provide additional directions to users with these comment characters
without cluttering up the final forms at all.

Here's my proposed addition to the form.  This would go immediately after
the inventory changes section, and before the List of files to be submitted
section.  Fine tuning/feedback is welcome.

I'd like to get this in place very soon for all releases.  Note that
the revert operation is one that can be used during retargets to save
the need for future merges for some files.

-josh

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

o List of files to be reverted or undefuncted (full pathnames from the
  src directory in the ODE tree, and operation to be done)

_|_ NOTE: These two commands effect changes in the submit pool, but are not
_|_ preceeded with bco/bci.  Please use these with caution; we would prefer
_|_ that you contact release engineering first if you plan to use these.  
_|_ Both of these commands create bsubmit.log entries.
_|_
_|_ revert: Removes file previously submitted into pool, replacing it with
_|_ a link to corresponding file in pool's parent backingtree.  Please first
_|_ compare the file in the submit pool with the file in the backingtree,
_|_ <pool>/link/src, to ensure that this will have the desired effect.
_|_
_|_ undefunct: Restores file into submit pool previously submitted defunct.
_|_ If you require further changes to the file, first use undefunct, and
_|_ then bco/edit/test/bci/srequest/bsubmit.  Remember that if you undefunct
_|_ a source file there may be accompanying new output inventory to be
_|_ listed in this form as well.

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