Brett Wooldridge <brettw@riseup.com> writes:
> Anyway, regardless of the diff issue, it seems like update could
> certainly send an MD5 hash along with the version.
The client doesn't send a checksum during update, however the
repository does send one in it's response when the update modifies a
file.
Here's how it works
- client commits file F with the text T and checksum C
- pre-commit modifes the text of F to T' with checksum C'
- client assumes T and C represent F at the new revision R and so
the wc is corrupt
What happens next?
Possibility one
- file F in the repository is still at revision R
- client runs update for F
- client's revision R matches repository's revision R so no
checksums are exchanged
- there is no indication that the wc is corrupt
Possibility two
- file F in repository has been modified to revision R' by some
other commit
- client runs update for F
- checksum C' from repository for revision R doesn't match checksum
C stored in the wc
- update fails with checksum error
Possibility three
- file F in repository is still at revision R
- F in the corrupt wc has been modifed from T
- client commits F
- checksum C from client for revision R doesn't match checksum C'
stored in the repository
- commit fails with checksum error
If you *really* want to modify text in the pre-commit you could hack
the client so that it doesn't carry out the post-commit client-side
processing, that's when the working copy gets corrupted. Doing that
would mean that the committed items would continue to show up as
locally modifed after the commit, but any attempt to commit then again
would fail with an "out of date" error. The user would then have to
run update and that would retrieve the the new revision as modifed by
the pre-commit and attempt to merge it into the working copy. The
merge would either succeed or leave local conflicts, but either way
the working copy would not be corrupt.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 9 00:16:02 2004