Chapter 8. CVS in the ArgoUML project

Table of Contents

8.1. How to work against the CVS repository
8.2. Creating and using branches
8.2.1. How do I ...?
8.3. Other CVS comments
8.4. CVS repository contents

8.1. How to work against the CVS repository

The CVS repository is a shared resource in the project. This means that once you commit your stuff it has the potential of getting in the way of everybody else's work in the project. For this reason special considerations are needed. This chapter describes the how you should do to limit the risk of causing someone else problems.

When you have done all the work, and all the testing and are about to commit something please do:

  1. Compile ArgoUML (build run or build package).

    This goes for all changes, even changes in comments.

  2. If your changes include removing files make a clean compile. (build clean followed by build run or build package).

  3. If your changes include removing public or protected operations and attributes make a clean compile (build clean followed by build run or build package).

    The build mechanism does not yet have reliable dependency checker enabled so this is the best way to make sure.

  4. If your changes include adding abstract operations make a clean compile (build clean followed by build run or build package).

    The build mechanism does not yet have reliable dependency checker enabled so this is the best way to make sure.

  5. If you have changed anything that has the potential of affecting something in a totally different part of the code like internal data structure, handling of exceptions, run all JUnit test cases and start the tool and do some more testing.

    If in doubt, run all JUnit test cases.

  6. Do a cvs update in src_new to make sure that you do not forget to commit any file and to make sure that no one else has committed anything in the mean time.

    Remember that if you do not commit all the files from src_new that cvs update found (marked A, R, and M) in the same commit then you would better remove those file from the checked out copy, update to get the original version from the repository and start over with the compilation.

    If someone else have updated a file (cvs update shown U, or no longer pertinent) please compile again.

  7. Commit all files that are included in a change at the same time.

    This reduces the chance of anyone getting an inconsistent set of files by updating in the middle of your commit.

  8. Commit often.

    Remember that the repository is also a backup copy of your work.

    If your change is so big and involves so many files that you would like to commit it for backup reasons but it doesn't compile or doesn't work or for some other reason should not confuse the main branch in CVS, create a branch to work in. Then when your work is complete, you merge the branch into the main branch.

Rationale: These ground rules is for the purpose of not stopping or hindering the work for anyone. Remember that there might be several developers working with different agendas and different efficiency (slower or faster) and the commits is the melting point of this.

Perspective: If this will take you an extra two minutes before every commit remember that if you commit something that will not work this will take everyone else (guess 10 persons) the extra time of looking at the compilation error or see the tool crash (1 minute), wonder why (1 minute), search for the error in his own changes (3 minutes), search for the error somewhere else (1 minute), glance at the mailing list to see if someone else has noticed this and send a mail (1 minute), wait for some response (1 hour wait), update (1 minute), compile (1 minute). This amounts to 10 hours wait and 1,5 hours extra work for all developers in the project.