Conference smurf::buildhelp

837.0. "re: submitting an older rev on your branch" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Tue Jul 12 1994 20:11

Date Of Receipt: 	12-JUL-1994 18:43:22.88
From: 	FLAMBE::jmf "Joshua M. Friedman OSF/UNIX SDE"
To: 	smart@DEC:.zko.flambe
CC: 	odehelp@DEC:.zko.flambe
Subj: 	re: submitting an older rev on your branch

James, ODE doesn't provide a clean way to do this.  Bsubmit does assume
that your private branch is (a) dedicated to a submit and is (usually)
expendable (to be outdated) when the submit is done, and (b) bsubmit
definitely always picks up the final rev on your private branch.

There are two ways you can go:

    1) use the current branch for your submit, and save your new
	work on the side; this may be simplest:

	    this requires "backing up" one rev - i.e. outdating the
	    final (.3) checkin, first transferring the new work to a
	    new branch (or just saving the work in a tmp file)
	    (note that you're first checkin is #.#.#.2, second
	    checkin is #.#.#.3; and #.#.# = James_Smart_origsandbox)

		cp file file.save
		bco -o3 file
		    (will outdate rev James_Smart_origsandbox.3)
		bsubmit file
		    (take the outdate default option)
		resb submit-pool
		bco file
		incorporate file.save contents after file header,
		    keeping the header as ode "wants it"
		bci file

    2) use the current branch for your new work, and create a new
	branch for this submit:

	    to do this, you'd make a new sandbox (you can't have the
	    same file out in different sets in one sandbox, so you need
	    two sandboxes), and bco unlocked the rev you want, then bco
	    locked the file for edits, then copy the file you want
	    overtop the locked version.  (first diff to ensure no new
	    submits have come along.)  You want to be careful not
	    to trash header information.  'bmerge' does much of
	    this for you, but it's slightly less predictable at times:

		workon -sb newsanbox
		bco -u -rJames_Smart_origsandbox.2 file
		copy file file.save
		bco file
		incorporate file.save contents after file header,
		    keeping the header as ode "wants it"
		bsubmit file
		    (take the outdate default option)
		exit

	    -or-
		workon -sb newsanbox
		bmerge -rJames_Smart_origsandbox.2 file
		    (check file very carefully)
		bsubmit file
		    (take the outdate default option)
		exit

	    *then*

		workon -sb oldsandbox
		bmerge -r$NEW file
		    (this will update your sandbox's .BCSconfig, which
		    keeps check-out rev history; without this, an
		    unexpected merge will occur during your eventual submit,
		    and will incorporate new header info)
		    (check file very carefully)
		bci file


Questions?   Good luck....

-josh

(p.s. please send questions like this to odehelp not me; there's more
coverage that way; I've cc'd odehelp on this response --thanks)


-------
From [email protected]  Tue Jul 12 15:36:45 1994
Delivery-Date: Tue, 12 Jul 94 15:36:46 -0400 Return-Path:
[email protected] Received: from abelia.zk3.dec.com by
flambe.zk3.dec.com; (5.65/1.1.8.2/30Mar94-0502PM)
	id AA04385; Tue, 12 Jul 1994 15:36:45 -0400 Received: by
wasted.zk3.dec.com; (5.65/1.1.8.2/26May94-1021AM)
	id AA10211; Tue, 12 Jul 1994 15:36:44 -0400 Date: Tue, 12 Jul
1994 15:36:44 -0400 From: James Smart USG <[email protected]>
Message-Id: <[email protected]> To:
[email protected] Subject: ODE question


I've been pointed toward you for an answer on the following:

Say I've:
    checked out a file from a tree,
    made a change and checked it in (ie now local rev 1.1)
    generated an srequest
    made another change and checked it in (ie now local rev 1.2)
    got srequest approval and want to bsubmit rev 1.1 into the
       main tree.


How could I do this ?  Is it possible to specify an exact rev to
bsubmit, or does bsubmit always use the latest rev ?
(Note: a second srequest would be filed shortly for the mods in rev 1.2)

I can certainly hold on to each rev, outdate my rev tree, check 1.1
back in, bsubmit, then check out and apply 1.2 again - but it sure seems
awkward and loses the original submission dates.

How is one to actually handle the above scenario ? Was I supposed to have
two sandboxes - one w/ rev 1.1, and another for 1.2 ?

Thanks.

-- James