The source code 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 page describes what 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 the following:
- Compile ArgoUML (build run or build package).
- This goes for all changes, even changes in comments.
- If your changes include removing files make a clean compile. (build clean followed by build run or build package).
- 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 a reliable dependency checker enabled so this is the best way to make sure.
- 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 a reliable dependency checker enabled so this is the best way to make sure.
- If you have changed anything that has the potential to affect 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.
- Do a svn status in trunk to make sure that you do not forget to commit a file and a svn update 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 trunk that svn status 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 has updated a file (svn update shown U, or R) please compile again.
- 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.
- 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 trunk in the subversion repository, create a branch to work in. Then when your work is complete, you merge the branch into trunk.
Rationale: These ground rules are not intended to stop or hinder anyone's work. Remember that there might be several developers working with different agendas and different efficiency (slower or faster) and the commits are 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.