[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 4908 - trunk/subversion/libsvn_fs

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-02-16 12:50:06 CET

striker@tigris.org wrote:

>Author: striker
>Date: 2003-02-15 16:48:10 -0600 (Sat, 15 Feb 2003)
>New Revision: 4908
> trunk/subversion/libsvn_fs/reps-strings.c
>* subversion/libsvn_fs/reps-strings.c
> (rep_write_baton): Add md5_digest field to store finalized md5.
> (txn_body_write_close_rep): Use the md5_digest in the baton instead of
> copying the md5 context and finalizing that.
> (rep_write_close_contents): Finalize md5 context and store it in the baton.
> Move a comment from txn_body_write_close_rep to here.
Bravo, way to go. Why use batons of not to keep state in them?

>+ /* ### Thought: if we fixed apr-util MD5 contexts to allow repeated
>+ digestification, then we wouldn't need a stream close function at
>+ all
We want a close-stream funciton ayway, for other reasons -- e.g., for
cleaning up temporary memory, so that it doesn't lie around until the
end of the txn.

>-- instead, we could update the stored checksum each time a
>+ write occurred, which would have the added advantage of making
>+ interleaving reads and writes work.
There won't _be_ any interleaving reads and writes. You only write to a
rep during an uncommitted txn, and nobody else can get to it while
you're doing that. It would be a huge bug if somebody saw a half-written
file in the repo and could actually read it as if it were complete.

> Currently, they'd fail with
>+ a checksum mismatch, it just happens that our code never tries to
>+ do that anyway. */
That just means we don't have the huge bug I mentioned above. :-)

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 16 12:51:01 2003

This is an archived mail posted to the Subversion Dev mailing list.