As many other lurkers are doing, I'm in the process of evaluating subversion
for our software development shop. We currently use scripts over sccs to do
our source code control on SGI IRIX (UNIX variant). This is similar to CVS
in that it is also a file based source code control mechanism. We maintain a
human readable baseline that is automagically checked out of sccs whenever
files are checked in after being worked on by a developer.
In our current procedures each developer copies the files that he needs to
work on to his local space and edit/compiles these in with libraries that
are maintained for the baseline. So in his personal workspace are only sees
those files that has changed for the particular project being working on.
When he is satisfied that the changes are complete (whether it's a bug fix
or enhancement), then there is a set of procedures that are followed to get
the file checked into the baseline. One of the steps is for others to
examine the code that has changed (code peer review).
Now for the question: In the subversion way of doing things, the developers
working copy is the entire contents of the baseline. How is a reviewer to
know which files to look at in doing the code peer review? In our current
scheme, it's simply the files that are in the directory. In the subversion
scheme it's not so obvious how another developer would know which files have
changed so he can review them. Note that this is not a small project. There
are some 40 directories and 2000 files that we are talking about.
What are others doing for code peer reviews?
Received on Thu Jan 13 23:31:56 2005