This is probably related to
http://subversion.tigris.org/issues/show_bug.cgi?id=443
Thanks so much for taking the time to find out how the corruption
occurred! (For those who didn't see the context, the end of solo's
mail quoted an earlier request from me for a repro recipe).
solo turn <soloturn99@yahoo.com> writes:
> it happenend with two working copies, one on nt, one
> on unix. prerequisits:
> 1. the server had a broken post-commit hook
> 2. the client on nt had a broken diff3
>
> i think the following is broken:
> - a failure in the post-commit-hook
> should NOT prevent the update on
> the wc (the update is done in
> the repository).
Yeah, this is the part that relates to issue #443. We need a way to
report post-commit errors to the client, such that a) the client still
learns of the error, but b) the client's own operations are not
disturbed nor interrupted by the error.
> - maybe: a failure to merge an update
> should not result in a checksum
> error, when in the meantime somebody
> else changes the file to a new version.
I'm not sure I understand this?
Are you saying: when in the post-commit stage on the client side, we
should never bump the revision number of the wc file unless we also
reset its checksum? In other words, that these actions should be
linked together -- either all happen, or none happen:
- revision number is updated
- text base is updated
- checksum is updated
If that's what you mean, then yes, you're absolutely right. It's a
bug if these things don't happen together.
> - IF there is a checksum error, then
> why not merge it anyway? is a different
> checksum not THE indicator for
> "please merge"?
I'd have to be in the code context to answer this question. In
general, if we are sending svndiff data based on a text-base, OR
receiving svndiff data to apply against a text-base, then we use the
local checksum to make sure that text-base is still okay.
Can you file a new issue with your reproduction recipe, and mention
"issue #443" somewhere in the description of the new issue?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 17:47:20 2002