Versioning, patchs, working with CVS

Sunday, 16 January 2005 20:34

I present You here some tips to deal with CVS integration into eclipse.

Tips

The tutorial ship with Eclipse is quite good, take a look in HELP or search (cvs) into the help for articles..

Rules:

If You have a huge number of Projects in Your workspace, always try to have closed version of these especially if you are not supposed to change them.
Releases should follows an X.Y.Z convention where:

X = The major release number
An increment of this number generally indicates a significant change to the code base. The increment may be completely incompatible with prior versions.
Y = The minor release number
An increment of this number usually indicates a significant change to functionality or architecture but with a moderate to high level of backward compatibility with previous versions.
Z = The maintenance release number
An increment of this number usually indicates bug fixing within the X.Y release and possibly small enhancements and limited new features. These versions are expected to be fully backwardly compatible with previous increments.

P1X project 1, version X, in workpace
P2Y project 2, version Y
p3Z project 3, version Z
P1H project 1, HEAD version

Case A: You are continuing the development of a project ...
Your team has reach a milestone, and want to continue development of the project . Happen 98% of the time

IF (you decide to make a change on P1_X) AND (P1_X is the latest closed version of P1) {
        Compare project P1_X with the project P1_Head;
        IF (P1_X identical to P1_Head) {
                Load P1_Head code;
        }
        ELSE {
                IF (P1_Head code is worth loading/using) {
                 Load P1_Head code;
                 Compare P1_Head with P1_X, and merge changes if needed to code in workspace;
                 //You have now a open edition of P1 in workspace which is a merge of P1X and P1H
                } ELSE {
                 jump to case B; 
                }
        }
        Continue development;
}

Case B:

You want to make a patch on a project...

The version of the project has already been deployed or sold to customer, and
Your actual code may be a lot more advance, but not finished, not tested, possibly breaking interfaces of other components and
You prefer to continue development on the old version to reduce risks of instabilities.

//old status of a project which have a problem/your prefer 
Load P1_X in workspace;  (Team - replace with - choose version P1_X) 
On P1_X, create a branch (Team - create branch - name it for ex: P1_X_b01);
Develop, test, develop;
Commit the branch (Team - commit : this put code in its own HEAD)
When the branch is stable, create a version P1_X_1 for example (Team - Tag as verion)

Decide if now if the change done on P1_X_1 are worth to bring in P1_Head, if so You will have to follow Case A