Re: recent client-side corruptions and Alpha

Ben Collins-Sussman <sussman@collab.net> writes:

> 1. Suppose your working copy has file 'foo' at revision 1, and you
> modify your working file to have local mods. The working file is
> now effectively r1+M.
>
> 2. You commit, creating revision 2 on the server. But somehow, in wc
> post-commit processing you crash. You crash in such a way that
> foo's entry has it's working-revision bumped to '2', but somehow
> the old rev 1 textbase is still installed (!)

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.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org