[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pre-commit transaction modification question

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-02-12 03:53:08 CET

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

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

This is an archived mail posted to the Subversion Users mailing list.