Updating Brat source code.
Recommended procedure when committing updates to brat or brat sub-directories.
With an increasing number of people working on Brat as well as other pieces of software it is important to ensure that updates are properly done with a minimal negative impact to other users (hopefully a lot of positive impact). There is always a problem with multiple people working on common software as also described in the CVS manual. CVS can assist in resolving simultaneous updates/commits but the users in the end have the main responsibility.
It is strongly recommended to go through the following steps. The following assumes you have a complete checkout of BRAT, but applies as well if only a subdirectory has been checked out.
1.. Perform an update from CVS to ensure your code has all the newest committed changes.
a.. Hint: execute cvs -n update brat > upd.lis. This will create a list of actions CVS will want to execute. Look for the following prefixes to list of files
a.. M - the code in current directory has been modified ie. The pieces that will be put back into the CVS repository at commit time.
b.. U - files that have been committed by others into CVS since the last update and or checkout.
c.. C - files that have been committed by others into CVS since the last update and or checkout and where YOU have also made changes. These are file to pay particular attention to. At the update CVS will merge the two files and may create conflicts. Files with conflict have to be manually inspected, and corrections made to get code even to compile. CVS inserst <<<< , >>>> and === lines around section that could not be handled by the merging algorithm. Remember that event if no conflict appears the code may logically not work either.
d.. A - Files that has been deleted from the repository. The present local copy will be deleted.
e..
1.. Perform the actual update. Cvs update brat
2.. Remake the directories and all of brat from scratch i.e.
a.. Cd brat ; make clean; make install SHOULD BE EXECUTED.
1.. Ensure that your own tests as well as the standard ones in brat/test still executes.
2.. If this is ok you are ready to commit
a.. Cvs commit brat
b.. Make sure that you add relevant test to the log file for each section. 1-4 lines are optimum length.
c.. E-mail to brahms-dev-l@bnl.gov a more detailed description of changes. In particular regarding substantial changes to classes, data objects etc.
a) The cvs log comment should be meaning full. This may require that
checkin is done at a sublevel
and not at once.
b) The code should have comments given the history of changes in some
more detail put in the top of the .cxx code just before the first
include files . with date/name/changes. e.g.
// December 1999. Modified code to deal with the TPC raw data as
defined by KO
// in the Dec 10 document.
//
// May 18, 2000, FV
// Moved dealing with RICH detector from FFS section to
// BFS part.
as inserted today in BrRawDataInput.cxx
c) comment should NOT be dispersed into the text.
-- A message should be send to the brahms-dev-l@bnl.gov listserver
indicating at a minimum what directories have been modified,
preferentially what files , and some overall commenst on what was
done.
-- For changes to be made in more fundamental classes e.g.(at the time
being) base, raw, db, geant, geometry,. the core developers should be
contacted before committing to CVS.
-- If you want to make changes to a directory for which the main
responsibility is another detector (group/person) it would good to
discuss such changes, unless they are purely cosmetic.
-- For changes to Tracking / Tpc stuff consult/discuss with the larger
group of tracking people (using the dev-l listserver.
--------------------------------------------------------
Flemming Videbaek
Physics Department
Brookhaven national Lab
tlf: 631-344-4106
fax: 631-344-1334
email: videbaek@bnl.gov
This archive was generated by hypermail 2b29 : Thu May 25 2000 - 16:46:24 EDT