On Jan 17, 2013, at 11:53 PM, Benny Malengier <benny.malengier@gmail.com> wrote:

Is this because you use git?

If so, it would be interesting that you use a devel branch, use git squash to combine the commits in master (http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash ), and use the single commit then for push to subversion. That would make it easier for the subversion users as wel as for code review.

Yes.

Yes, that's what I did (though with git rebase -i, not git merge -- git merge and git-svn don't get along at all). I cut about 50 commits down to 8 or 9 (the others are fixes to pre-existing bugs that I made along the way) to present a progression of related changes. This way the commit messages can explain what's going on in each changeset (rename files, replace module x, etc.) rather than having a single massive changeset that does a dozen things at once, and no way to separate which bits of the changeset implement what changes. It might complicate code review if you do it one changeset at a time, because (as in the instant case) you think of an improvement in one only to find that I did exactly that two changesets later, but if you're examining a file down the road and trying to understand what it does and why it's implemented the way it is, having an understandable history makes the task much easier.

Regards,
John Ralls