My opinion: Really small complete changes at one time shouldn't need too much explanation --- I'm not saying none. Big changes shouldn't be allowed in if they're not part of a JIRA that fully explains them. Small changes part of a big change should be associated with a JIRA and explain what part of it they're addressing and how. If you put the the JIRA on top of the svn commit example: TUSCANY-568
The svn history shows up in the Jira I also practice include the full url on the second line so it easy for anyone looking at it from the mailing list to quickly get to the jira: http://issues.apache.org/jira/browse/TUSCANY-568 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] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
