Philip Martin <philip@codematters.co.uk> writes:
> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 14 00:21:52 2002