Experimental Physics and
Industrial Control System

[email protected] (Matthew Needes) · Mon, 19 Jun 95 12:21:00 MDT

NOTICE TO ALL REMOTE CODE DEVELOPERS !

Changes to EPICS source were made recently that inadvertently
removed other changes made to the same source files.

This occured because a remote developer was not careful using CVS.
While CVS has solved many of our problems, it is not always intuitive
to use, and in fact during the early development of EPICS I think I
made the mistake once.  Luckily I caught it after diffing the files.

This is probably what happened:

1.  The developer obtained an older release of EPICS beta (beta1, for example),
	then made modifications to it at a remote site.
2.  Several months later the developer checked out the CURRENT source at APS
	(beta13).
3.  The developer then replaced the source files with the new "correct" versions,
	and then commited the changes.
4.  CVS, thinking that the new file was a verbatim replacement, removed all the other
	changes made since beta1.

The mistake was made in step #2.  The developer needed to check out the
source given either a DATE or RELEASE tag of the source that was originally
obtained (e.g.: beta1).  This tells CVS to merge ALL changes, instead of just
deleting all but one.  This exact method is detailed near the end of the EPICS
Source/Release Control manual.  In fact, this method was used to integrate
pre-CVS source from LANL into APS during the original integration of 3.12.

An even simpler method is to have checked out the source at APS originally, and to
have just left the tree alone during the months of development.  But in some cases
this is not possible.

Here are some specific instructions:

Method 1:  (simple method, use if possible)

1.  Check out the source at Argonne (beta13, for example).  LEAVE THIS TREE
	CHECKED OUT FOR THE DURATION OF THE MODIFICATIONS.  RECORD THE DATE
	YOU CHECKED OUT THE SOURCE IN CASE YOU LOSE THIS TREE.  IF YOU LOSE
	THIS TREE YOU NEED TO FOLLOW METHOD 2 INSTEAD.
2.  Copy the tree to your remote site.
3.  Several months pass by, you make your mods to the code.  Make a note of
	what files were changed.
4.  Go to the original source at Argonne, replace the files that were changed.
5.  Fix conflicts and commit.
6.  Hand-verify that no other changes made to the source were lost.

Method 2:  (if you deleted the original checked out tree at APS, or you never had
		one in the first place.  This method is detailed in the S/R manual)

1.  Obtain a release of EPICS.  Record the release TAG of the source if you obtained
	it from a release Tar file.  Record the DATE you checked out the source if
	you obtained it by checking it out of APS' repository.
2.  Copy the tree to your remote site.
3.  Several months pass by, you make your modifications at your remote site.  Make a
	note of what files you change.
4.  If you have a release TAG:

	cvs checkout -t "TAG" base config extensions

    If you have a checkout DATE:

	cvs checkout -D "DATE" base config extensions

5.  Replace all the files in this new tree that were modified at the remote site.
6.  Update these new files either individually or at the top-level, using

	cvs update -A

7.  Fix conflicts and then commit changes with "cvs commit".
8.  Hand-verify that no other changes made to the source were lost.

Note:
	If you lost the date or tag of the original release, the best bet would be
	to use the date on your tar-file.  However, if you make "GUESSES" like this
	you should always hand-verify the code to make sure nothing untoward happens.  In
	fact, one can argue that you should ALWAYS hand-verify the code, since its a
	lot easier to find these problems during the commit phase of your changes rather
	than the debugging phase of an EPICS release !

Thanks,
	Matt

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System