+1 - little and often

Also at OSCON, Fitz's Poisonous People session referred to the code
bomber - large changes are hard to review and as a result don't get as
much buy in from other people in the community.

One way to address this is to say what you are planning to do, then
spin off a working branch, make a series of small changes there, and
roll it back into the trunk. This makes it easier for others to
participate in the design and implementation.

--
Jeremy

On 7/28/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
I attended a Subversion Best Practice session yesterday here at OSCON
and "Committing often and in small chunks"  was near the top of the
presented list.  A related best practice mentioned was:

    "Use consistent log messages"

This makes sense to me too although consistent use of  "I fixed a bunch
of stuff" is probably not the best way to go.  The message should have
some real content to guide a reviewer and this is easy to do if the
commit is a "small chunk".

--Kevin

ant elder wrote:

> After being away I've been trying to catch up on all the changes and for
> some commits its not so easy to work out whats going on.
>
> Big commits including multiple changes and vague or brief commit messages
> make it really difficult to review changes. There was an Subversion Best
> Practices talk at ApacheCon which talked about this pointing out the
> importance of making it easy to review changes, especially with the
> Commit-Then-Review style of working used be most Apache projects. The
> talk
> pointed out things like: Commits should be for discrete changes with
> commit
> log messages that make it easy to understand the change. Its not so
> hard to
> do several commits instead of one big one, especially if you commit early
> and often, and that also makes development more open than just committing
> big chunks of finished function which has been developed off line.
> There's
> also plenty of space in the commit log comments for whole sentences
> ... or
> even several sentences if its a non trivial change.
>
> Does this all sound like reasonable approach to everyone?
>
>   ...ant
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to