1. CVS revisions UML diagram

2. CVS tags UML diagram

3. CVS is line-oriented
CVS just records that a line has changed, been added or deleted
CVS stores differences between consecutive versions as line modifications
Consequences
better not put several statements on a line, e.g. int i=0; int j=compute(2);
always format the source the same way (indenting, spaces, empty lines); better use the IDE feature
otherwise CVS will see artificial differences

4. Merging with CVS Merge always involves 3 files original file
modified_1 file
modified_2 file
What CVS does:
Apply to modified_2 the modifications that lead from original to modified_1

5. Merge example 1: user1 & user2 add lines

6. Merge example 2: user1 removes 1 line

7. Merge example 3: conflicting change

8. Branches Why make a branch?
to develop a new feature or fix a bug without impacting other people
to be able to choose what to include in next release (develop once, deliver many times)
Traceability: a line of development is associated to a task
Strict policy
No development on the trunk
Major and minor releases on the trunk
Correctives releases can be on branches depending on situation

9. Branches: justification of strict policy
Strict policy - No development on the trunk
this way each branch has a definite goal/task (new feature, bug processing, ...)
avoid the overload of work due to everybody in the team integrating continuously everybody's updates
avoid the lack of traceability when working on the trunk
merges are traceable
note that this is different from common CVS practice (e.g. in open source projects)
collaborative work still occurs, but in branches

10. Branches Trying to commit on an ordinary tag :
cvs -z5 commit -m "try to commit on sticky version" jmvanel.txt
cvs server: sticky tag `nice_new_feature_2' for file `jmvanel.txt' is not a branch
cvs [server aborted]: correct above errors first!

11. Branches Policy: each feature on a different branch
Good for traceability !

12. Branches
Policy: features + releases

13. Start a new branch Create a branch
Start from a tagged version (e.g. Version_1 ):
Extract the tagged version in a new directory, using Checkout module
Menu Modify/Create a branch on selection
Give a name to the branch, e.g. Version_1_branch
Check box :
Check that the files are unmodified before branching
Work on a branch
Select the appropriate directory
Click on tab « sticky options »
Retrieve a rev./tag/branch
Choose the branch name: Version_1_branch
Then you can commit

14. Branches Create a branch on a branch Extract the first branch
Put a tag on that branch
Update your local copy to retrieve the tag
Menu Modify/Create a branch on selection
Give a name to the branch
Checkbox: « Check that the files are unmodified before branching »
Branch on branch use
Test
Debug
Customer specific development

15. Traceability of merging
Graphic tree is incomplete
It does not include merging points
Because CVS does not keep that information
Have to remember merged branches
Tagged version
Set of merged branches

16. Différentes politiques de gestion d'un référentiel CVS
Simple: tout dans le tronc
idem, mais des versions à chaque livraison
idem + branches de maintenance
idem + branches de développement
Ne pas confondre:
répertoires (paquetages) et branches
Versionnement et sauvegardes

17. Example policy for directories
1_ProjectOrganisation
project development plan
configuration management plan
document list
deliverables plan
WBS=Work Breakdown Structure (activity report)
2_Requirement
3_Specification
4_Analysis
5_Design

18. Example policy for directories
policy for directories (continued 1)
6_Products
Source files
Build scripts / procedure
External libraries / components
Test case source files
Tests data
Executable
Installation tool
Operation and user manuals
Version description document
Build environment description
Execution environment description
Example policy for directories

19. Example policy for directories
policy for directories (continued 2)
7_Validation
Validation plan
Tests specifications
Tests execution reports
8_ExternalDoc
All the documents related to the project but not generated by the project team that cannot be put in the previous configuration items (consequently not necessarily the latest revision).
9_Miscellaneous

20. Good Practices 1
Ask for backup to cvs administrators before sensitive operations
Contact administrators
To have support
To reorganize data on repository
When having problems
Don't be afraid to tag more than necessary…tags can be removed

21. Good Practices 2 Traceability through Commit comments
should indicate the what and the why
Should refer to corrected bug, or feature/requirement , or design document
No commit without passing tests
The worst thing : commiting with compilation errors
No empty comment!
Commit related files in one time

22. Good Practices 3 don't keep old working directories
Use cvs release to ensure that nothing commitable remains
avoid too many non-CVS files in your working directories
Keep System clocks in Sync
Automate build Process completely
including automatic retrieval of the source files from CVS
Automate tests as much as possible

23. Good Practices 4
Merge bug fixing last