7.2. When Committing to the Repository
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 chapter 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.
