Branches obviously have there place, but given whats just happened with the
trunk and sandbox i don't think it would hurt to be a little cautious. IMHO
trunk is the place for day to day dev unless there's very good reasons. We
had the celtix binding initially start with trying to be developed in the
sandbox and it didn't work so well so was moved to trunk. Also, there's
enough work to keep up reviewing all the changes in trunk without having to
also monitor everyones sandboxes. Our Mentor Dims posted on this topic a
while back on another project:
http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200512.mbox/[EMAIL
PROTECTED]
...ant
On 7/28/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
This reminds me of another best practice from the Subversion session:
"Do not fear branches"
Jeremy Boynes wrote:
> +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]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
