Re: SVN Commits

[Jeremy Boynes]

I agree, trunk is definitely the place for main stream development.  
Normally that would be fairly evolutionary with small changes  
committed often which should prevent disruption to other developers  
(assuming basic things like it builds).

The issue Dims and Paul were discussing is the same one that we ran  
into with the Celtix binding: major refactoring of the trunk breaking  
or making obsolete things that were not included in the refactor. I  
think though that branches can help here - not branches for the  
extensions but creating a branch to do the refactoring. That way it  
becomes the responsibility of the people doing the refactoring to  
make sure that the new version works with the old extensions.

I do think though that people should review changes throughout the  
codebase - especially areas that they are interested in. That may not  
be something totally experimental in someone's sandbox but should  
include something like a refactoring branch where there is already  
community intention to move it back into the trunk.

--
Jeremy

On Jul 28, 2006, at 9:26 AM, ant elder wrote:

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]




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