Hi, pipfsta...@openmailbox.org wrote on Thu, Aug 10, 2017 at 08:07:44PM -0000:
> I want to fill https://openbsd.org/plus61.html Wow, that would be useful, but it's a lot of work. Multiple days of full-time work, probably. In the past, people who did that have usually started from a mailing list archive like http://marc.info/?l=openbsd-cvs, and then looked at CVS as required. Starting from cvs2cl would be fine, too, and mostly equivalent. Maybe even a bit easier because you see the revision numbers right away. You only need to look at changes involving two-component revision numbers (x.y), those are on the MAIN branch, where all of -current and all releases happen. Four-component revision number (x.y.z.t) are on branches, hence irrelevant. To see whether an individual revision of a file was before or after release, just look at the log for that file, and where the tag is. Note that in rare cases, a release version of one file can be *newer* than a post-release version of another file - but at most by a few days, and only in those cases where Theo manually retagged a file to put a last-minute bugfix into the release. In extremely rare cases, one person may have changed several files with one "cvs commit" command (and hence all with the same date and commit message), and some of the resulting file revisions may be part of the release, while others may not. To get a rough first impression about the time range in which the cutoff happened, look at: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/conf/newvers.sh Stuff *newer* than the "unlock" change is *usually* post-release (except when Theo retagged something), stuff *older* than the "unlock" change is *usually* in the release - but a few changes may have gone in before the unlock change. So be careful with changes in the timerange of about two days before to about seven days after. Some of them may be in the release, some post-release, independent of their chronological ordering, even though they are all on the same branch! > Thus I need to obtain all commit messages for commits done between > 6.0 release and 6.1 release. > But cvs2cl just spits out all commits done in every branch without > marking them with tags they are assigned to. Again, ignore everthing with four-component numbers, use all the rest. > So I can't see if a commit was done before or after 6.0 release, Not from cvs2cl, no. That is a limitation of that particular (quick and dirty) script, not a limitation of CVS itself. > or if it is a part of the -STABLE branch for the 6.0 release, You *can* see that from cvs2cl output. Those would have four-component revision numbers. > or whatever else there is going on in the source tree. Nothing else is going on in the tree. In OpenBSD, side branches for development are strongly frowned upon and are used extremely rarely, and none have been active for some years now as far as i remember. > Even just getting info on the points (commit IDs) where the code > was frozen for the release would be very useful. But I failed > to find it in mail archives. Your biggest problem is that you are trying to figure out how a tiger looks like by asking specific questions about its roots, its stem, and its leaves. In git, everything revolves around commits and files are of very little importance. In CVS, the basic concept is completely different. Everything revolves around files and their revisions. The revisions of one file are independent of the revisions of any other file, and the notion of a "commit" is practically meaningless. Most definitely, commits do not have parents and children, ordering them chronologically is completely useless, and in particular tells you nothing about which revisions of which files are or are not part of a release. Yours, Ingo
