In our case it's not simply a matter of being paranoid, but in the
beginnings of development the statement was made that the baseline was a
version that always worked (i.e. didn't crash in obvious ways and would
compile). This was instituted because there were many cases where people
would put stuff back not-tested ("it compiles on my machine, so it must
work" kind of mentality). At that time we required at least one other person
to look at your code before putting it back into the baseline. Now we've
instituted group meeting peer-reviews, a mistake IMHO, but they didn't ask
me.
I've considered the committing to private branches approach. I'll need to
play with this to see how it will work. Not sure if it's easier to merge
between a branch and the trunk, or between a working copy and the trunk.
Unified diffs don't seem useful to me. We have gotton used to (spoiled by?)
graphical difference programs. The one we actually like the best is gdiff on
the SGI. I tend to use tkdiff and others in our group uses windiff. These
tools allow you to see the context of the changes.
I did try the "svn status" command where everything was on my local machine.
It took 1 minute 45 seconds to execute. This is probably not going to be
acceptable. However, the TortiseSVN Check for Modifications menu only took
15 seconds. I haven't tried this across the network yet though I will be.
Machine details:
2.8 GHz P4
1 Gbyte RAM
Windows XP
Using svn:: for repository access.
By the way, thanks for the reponses!
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Thursday, January 13, 2005 4:55 PM
To: Geoff Krapf
Cc: Rule, Chris; users@subversion.tigris.org
Subject: Re: subversion and code peer reviews
On Jan 13, 2005, at 4:33 PM, Geoff Krapf wrote:
> It seems like "svn status" would work fine. That shows which files
> have been modified in the working copy.
>
>
Most subversion teams also set up the repository to send email
everytime somebody commits. The email contains unified diffs of the
changes, so peers review the changes after they're already committed.
Discussion happens on email, and after receiving feedback, the original
committer goes and makes more followup changes.
This assumes, of course, that everybody trusts one another. "Commit
first, get feedback second." If your company is really paranoid, then
people can commit to private branches. People will still be able to
review the changes in email, and after feedback is done, the changes
can be merged from the branch to the main 'trunk'.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 14 21:50:33 2005