> * Use some kind of checksum on the wire and in the DB. Given that whatever
> is in source control is probably quite important, it would be a Good Thing
> if we hashed/checksummed the data.
For checksums on the wire: I am really hesitant to solve problems
which (a) haven't been observed in the past (to my knowledge), and (b)
are supposed to be solved by our transport layer. (I'm assuming here
that CVS doesn't verify wire transfers with checksums; I could be
wrong.) On the other hand, if it can be done purely using HTTP
mechanisms, it wouldn't be the end of the world to do so.
For checksums in the DB: Larry makes a good argument that if you're
storing very valuble data, you want checksums (or some other form of
redundancy) in your permanent storage, and you want to periodically
verify that none of the data is corrupt. On the other hand, we're not
particularly targeting very expensive data; we're targeting the open
source community, according to our web pages. So, I would say: we
should ensure that our DB format is extensible enough to support
adding per-revision fields, and we should treat this as a "some day"
feature unless someone feels inspired to implement it right away.
> * Diff formats.
I feel like you're conflating the XML delta format with svndiff.
We've always intended to use gnudiff format for passing stuff around,
and it can be embedded in an XML delta just as easily as svndiff can.
(Our code currently only deals with svndiffs, but that's a temporary
state.)
I think you're correct, though, that the editor interface has to
change in order to produce anything other than svndiffs. (It doesn't
have to change to a pull model, but text delta windows aren't going to
hack it.)
Received on Sat Oct 21 14:36:27 2006