[development] Suggestion for people releasing new modules and themes into CVS

[Derek Wright]

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)