On 10/13/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> Exactly. You can't see the diffs when Karl squirrels away patches in his
> local disk, either, and that's fine. What matters is the change dropped
> into a live branch -- that's the diff to review. If Karl wants early
> feedback on his work in progress, then he needs to use a regular feature
> branch and work within the established policies for commits to our tree.
And if Karl *doesn't* want feedback on a branch, what's wrong with
prepending this to the log message:
*** This is a checkpoint commit--please don't waste your time
reviewing it ***
I cannot even begin to comprehend this whole business about checking
diffs into a directory that our commit mailer ignores. We have a
version control system, we have branches. Ben and I have given
numerous talks on the importance of committing early and often. We
seem to be diving deep into a minor social problem with a half-baked
technological solution that just plain doesn't work with existing
version control tools (ever look at a diff of unified diffs? Enough
to melt your brain...).
So, to summarize: Please please PLEASE just do your work on a feature
branch, prefix your commit messages with a warning not to review, and
then encourage folks to review when you merge back to trunk. Nobody
requires that a feature branch compiles or contains code ready for
review at all times.
Please?
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 16 18:00:39 2007