This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: source mgt. requirements solicitation
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: <gcc at gnu dot org>
- Date: Mon, 9 Dec 2002 09:08:35 +0000 (GMT)
- Subject: Re: source mgt. requirements solicitation
On Sun, 8 Dec 2002, Zack Weinberg wrote:
> 0a. All data stored in the repository is under an end-to-end
> checksum. All data transmitted over the network is independently
> checksummed (yes, redundant with TCP-layer checksums). CVS does
> no checksumming at all.
Doesn't SSH?
(And CVS does checksum checkouts/updates: if after applying a diff in cvs
update the file checksum doesn't match, it warns and regets the whole
file, which can indicate something was broken in the latest checkin to the
file (yielding a bogus delta). This is however highly suboptimal - it
should be an error not a warning (with a warning sent to the repository
maintainers) and lots more checksumming should be done. In addition:
0aa. Checksums stored in the repository format for all file revisions,
deltas, log messages etc., with an easy way to verify them - to detect
corruption early.)
> 5. Should have the ability to generate ChangeLog files automagically
> from the checkin comments. (When merging to basic-improvements I
> normally spend more time fixing up the ChangeLogs than anything
> else. Except maybe waiting for 'cvs tag' and 'cvs update -j...'.)
The normal current practice here is for branch ChangeLogs to be kept in a
separate file, not the ChangeLogs that need merging from mainline. (In
the case of BIB the branch ChangeLog then goes on the top of the mainline
one (with an overall "merge from BIB" comment) when the merge back to
mainline is done. For branches developing new features a new ChangeLog
entry describing the overall logical effect of the branch changes, not the
details of how that state was reached, is more appropriate.)
--
Joseph S. Myers
jsm28@cam.ac.uk