Would it be possible for the server to pass the new checksum back to the
client
in the commit-response? WebDav is request/response, right? So, when the
client recieves the commit response, it compares C' with C. 100% of the
time
with a non-modifying commit hook, C' will match C. In the case where they
do not match (i.e. with a hook that augmented F), the client could
refresh it's
copy from the repository. This seems like it would be a sound validation
regardless of permitting a pre-commit hook to augment the file. There is no
transaction violation by the pre-commit hook, as the transaction is
still open.
There is no corruption of the repository possible, merely a client
synchronization
issue to resolve.
If you wanted a zero impact model in the nominal case, C' doesn't even need
to get sent in the reply if C and C' do not differ. It's presence would
indicate
that a difference was detected.
bw
Philip Martin wrote:
>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.
>
>
>
---------------------------------------------------------------------
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:18 2004