On Sep 13, 2006, at 10:24 AM, Khalid B wrote:
I imagined that some would disagree with this, for that very reason. The other side of the coin is clutter in CVS and RSS feeds, but I guess your argument wins.
i, too, *strongly* disagree with your original suggestion on this. the whole point of version control is keeping track of individual changes so you know when, who, and why any given change happened, so you can undo changes you don't like, and so you can more easily share those changes with others. fixing N issues in 1 giant commit completely violates many of the benefits of using version control in the first place... 2 immediate examples of why this makes life difficult: 1) if you need to undo a given change, but the same commit includes 4 other things you want, you're totally screwed. now you get to track down the various patches that were actually committed (something our existing practice isn't very good about -- you get a link to an issue id, but sometimes there are 60+ patches in the issue, and it's not always obvious which patch was actually used), undo the whole revision, re-apply the 4 patches you want to keep, re-test everything, commit it, etc. 2) you're looking at "cvs annotate" output to try to understand some code you're not familiar with. there's a weird line in the code that doesn't make much sense, you think it's a bug, and you want to know where it came from. you see it was last touched in revision 1.67, but when you look at the log message, there are 5 different issue #s. :( now you have to read 5 issues to try to figure out which one of them might really be the source of this change, and how it might relate to the problems you're trying to understand... avoiding "clutter" in the CVS logs and RSS feeds is looking at this completely backwards. don't read all the logs if you don't care about all the changes. ;) the solution here is to filter on messages you actually care about (i.e. the ones from projects you care about, or even the ones on specific branches of specific projects you care about). there are already many ways to filter your view of the cvs commits based on what you want to see (either on the command-line, in various GUIs/viewcvs ways, and via drupal itself, e.g. http:// drupal.org/project/cvs/3281). that's how to keep your signal/noise ratio high, not by trying to limit the overall # of commits in the repo. anyway, enourmous -100 to this practice in the first place, and it should by no means become a "guideline". ;) quite the contrary, the guideline should spell this out (with more concise language) and implore people to only make 1 change per commit...
Does this mean you agree with all the rest of my points?
yes, i think the rest of them look good. thanks for helping to document this wisdom. -derek (dww)