[development] Suggestion for people releasing new modules and
themes into CVS
drupal at dwwright.net
Wed Sep 13 18:12:45 UTC 2006
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
> 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
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.
More information about the development