"Brian W. Fitzpatrick" <fitz@red-bean.com> writes:
> 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?
Sure. Loosening up our (hitherto implicit) policies about creating
feature or experimental branches would be essentially equivalent to
using the "/checkpoint" or "/anarchy" directory. But I don't see any
reason to prefer the latter solution -- the former is just as good.
When a specific commit should not be reviewed, just say so. If later
commits on that branch *should* be reviewed, it might be nice for the
author to supply (in the log message) the appropriate 'svn diff'
command, since the diff will likely be between two non-adjacent revs
on that branch. I.e., review doesn't have to wait until the changes
hit trunk.
Somebody should document this somewhere!
I just did, in hacking.html.
r27267,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 18 02:46:08 2007