On 2011.1.28 4:22 AM, Marco Von Ballmoos wrote:
> We also use code reviews, so rolling back committed changes never really came
> up.
> Usually, problems were discovered only after several other commits had been
> made
> whereupon it was just easier to fix the fix and check in the new change rather
> than "roll back", which is, I think, what Neil was driving at.
This is kind of like saying you keep the parking brake on because if you go
any faster you might hit the car in front of you.
Code reviews are great, but requiring a review before every commit is a
parking brake on getting work done. You can't do anything unless somebody
else has said it's ok, requiring developers to all be second guessing each
other and spending time reviewing every little detail of each other's daily
work instead of relying on automation tools like tests and coverage analysis
and code tidiers. It's command and control for software development.
And I've used Aegis. I've CHAMPIONED Aegis. This was version control
DESIGNED around code reviews. You could not make a commit unless it built ok,
added tests, passed tests and the previous revision failed the new tests. I
thought this was the greatest thing since pegs on a BMX bike.
This is all complicated in that in the CVS model "commit" == "inflict on other
developers" (unless you're working on a branch... but you're not because
branches are complicated things in the CVS model and not to be made lightly)
whereas in DVCS a commit is more like a save and backup. In a DVCS you are
ALWAYS working on your own personal and easy to manage branch.
With this in mind, the seemingly pell-mell change everything, rebase, revert,
etc... makes a lot more sense because, done well, it only affects YOU. This
allows you to commit very early and very often which lets you work in small,
easy to review, log and understand chunks. If I make a mistake, I amend the
last commit. I will often write what looks like a sensible change, run a few
fast tests, commit and THEN run the full regression suite. Usually, it
passes. If it doesn't, then I stash away whatever new change I'd started, fix
the code, amend the last commit and bring my stash back in. Even if your test
suite only takes a minute, this is all reclaimed time. It's releasing the
parking brake.
Diffing against your last version now becomes a powerful debugging tool. The
diffs are small, and you know it worked last time you committed, that finding
the problem (or at least the source) becomes trivial.
And then, when your feature is ready, you push it out to everyone else.
Instead of getting one big wad, your reviewer now sees a series of small
commits showing the same logical steps you went through. You can use the
commit rewrite features to squish together some changes that don't help a
reviewer like "oops, typo" or "that was stupid".
How is this hating software? CVS has trained our brains so well that history
is involatile, branches are hard to maintain and commits mean pushing code
into trunk. It has trained us to make preventing any error from being
committed priority one. Instead, getting shit done should be the priority,
and your development process should be error tolerant.
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
-- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
by Tami Farmer
