Jim Blandy <jimb@red-bean.com> writes:
> > I'm not sure what the current MD5 checksum position is, or what the
> > plans are, but it should be possible the client/server to detect this.
> >
> > - Each full text has a checksum, stored or calculated on the server.
> >
> > - Each working copy text base has a checksum in the entries file.
> >
> > - The client checks the stored checksum against the text base before
> > committing.
> >
> > - The client sends the checksum to the server with the binary diff.
> >
> > - The server rejects the commit if the client's checksum doesn't match
> > the server's checksum.
> >
> > This should be sufficient to ensure that a corrupt working copy cannot
> > be committed.
> >
> > We could also have an 'svn repair' command that sends checksums to the
> > server to be tested and retrieves new text bases for those that don't
> > match.
>
> It's been a long time since I knew anything about the client, but
> doesn't it use a two-phase log/commit cycle for exactly these sorts of
> situations? When restarted, the client should be able to examine the
> log it left to see whether the transaction (not a repository
> `transaction', but a `transaction' in the sense of a bunch of
> operations on the working copy metadata that are supposed to be
> atomic) was completed, and roll forward or back as appropriate.
>
> At the very least, it should be holding some sort of lock while the
> working copy metadata is inconsistent, and notice that lock later.
>
> Of course, perhaps it is all designed to work with logs or locks, but
> the bug is in *that*. I don't know.
Yes, the client is designed with the aim of never getting a corrupt
working copy, but it may have bugs. Or the user may accidentally (or
deliberately!) corrupt the text base, or the entry file, outside of
the svn client.
By having the client confirm that it's text-base still has the
checksum given in the entry file, and by having the server confirm
that the entry file checksum is correct for that revision, it will be
much harder for working copy corruption to make it to the server.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 14 01:30:16 2002