On 7/18/2012 07:47, David Holland wrote:
On Tue, Jul 17, 2012 at 07:16:03PM -0400, Greg Troxel wrote: > If pkgsrc was using a different version control than CVS (something > like git and the ilk), then reviewing per-patch history on the fly > would be a cinch. Rather than use a better VC (and I've heard many of > you complain about CVS), we change the process to work around its > limitations. > > It's not about the VCS - the notion is that comments in code should > explain the reason the code is the way it is, and commit messages should > explain the reason for the change. (That's not special to pkgsrc.) > Reading all the commit messages that touched a file to find the one of > interest (and being sure you did that right) is quite hard, git or cvs, > especially if people are also sparse with commit messages. I've had > difficulty with this when trying to figure out patches that were added > many revisions ago and modified multiple times, often with only a > 'update to x' commit message. ...also if we were going to upgrade tools and improve procedures, moving to per-topic instead of per-file patches would buy a lot more bang for the buck.
I think that would be a big mistake. I could point out hundreds of patched files that were patched for many reasons at different points in time, with the current version of the patch being the aggregate. Per topic would have to be based on the preceding intermediate version of the patch, not original file. There's order issues, perhaps comprehensive issue (especially if a later patch erases an earlier patch), and of course it would be a nightmare to migrate to a new version of the software. All the per-topic patches would need migrating too.
to Greg -It may not always seem like it, but I do strive to have good comment messages that explain what the problem was, the solution, and any details that are pertinent. There is no way I'd get that kind of detail in a patch comment and of course a commit message covers the change set as an atomic unit. A properly used VC is going to provide a better picture than comment patches. (As a side note, I hope you aren't looking at GNU as an example where their commit messages are copies of changelog entries, which state what (NOT WHY) and the what is obvious from VC. At least you want to put the "why" somewhere, in this case the patches.)
John