source mgt. requirements solicitation

[Zack Weinberg]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

E> 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?

I assume it has to, since cryptography usually requires that.

> (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). 

I didn't know that.  But, as you say, it's not nearly enough.  (When
was the last time we got a block of binary zeroes in a ,v file and
nobody noticed for months?)

> 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.)

Worth pointing out that subversion doesn't do as much checksumming as
we'd like, either.

> 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.)

Unfortunately, this is not how BIB was done, and I'm stuck with the
way it is being done now (the normal ChangeLog files are used, and I
resolve the conflict on every merge).  Next time around, it would
certainly be easier to use a separate file -- but better still to
avoid maintaining the files at all.

zw