On 08/23/2011 09:07 AM, Johan Corveleyn wrote: > On Tue, Aug 23, 2011 at 5:13 AM, Neels J Hofmeyr <ne...@elego.de> wrote: >> I can reproduce the corrupted WC reported by David Wallace with 1.6.17. >> 1.7.x does not show this bug. >> >> I have attached a reproduction script that is roughly based on David's >> typescript, but is only a fraction of the size. >> >> The error occurs like this: >> >> - use Subversion release 1.6.17 >> - update WC >> - locally delete file 'foo' >> - commit >> - do *not* update. >> - merge, so that file 'foo' is added (e.g. from another branch). >> status becomes: A + foo >> - update >> - A tree conflict "local edit, incoming delete" is flagged. > > At this point, this seems remotely similar to > http://subversion.tigris.org/issues/show_bug.cgi?id=3526 "Commit of
Indeed, looks like we misinterpret absent/not-present states in both ways. Or should I say, misinterpetED :) > newly added file followed by move (or delete) of parent dir causes > tree conflict". Except that it's more like "Commit of deleted file > followed by a merge adding the same file to the parent dir causes tree > conflict". BTW: Does it have to be a merge adding the same file (A+), > or can it also happen with a plain 'add' of that same file (A)? No, it has to be an - add with history (copy or merge) - from a different branch or an earlier rev, i.e. copy-from differing content. > > In issue #3526 the conflict came from one of the 'entry-props' being > updated (the last-changed-revision number), while it was locally > deleted. I don't understand the internals too much here, but on the > surface it looks like a conflict between a local entry-prop being > updated (the copyfrom perhaps?), and the remote delete coming in. Or > something like that :-). I guess that this situation comes from the parent dir thinking the file should be there/not be there (as the parent dir is out-of-date) while the file's own status is the reverse, as it is up-to-date. Will test. >> The committed result (svn cat <URL>) is different from the on-disk contents, >> even though the file is claimed to be up-to-date. > > That's certainly a new result, one which I hadn't reached with #3526. > Nice! (well, not nice of course, but ... interesting :-)). Hmm, let me try that... No, since both the local state and the committed state have the dir deleted, there is no way to have differing contents. The WC corruption happens when the BASE text differs. (probably props affected too?) I've discussed with stsp on #svn-dev that we wonder why this hasn't been found in the two years that have passed, and that, looking at the upcoming 1.7.0 release that fixes these issues and noting that 1.6.x will only receive security fixes in the near future, we only need to bother fixing this on 1.6.x *if* it is possible to lose data with these bugs. That happens not to be the case. Issue #3526 ends up with a deleted dir and doesn't even reach a corrupted working copy state other than a nonsensical tree conflict. The issue found by David Wallace, verified by tests, does not happen when there are local modifications on the file in question. When there are local mods, the new content is committed and no WC corruption occurs. Such WC corruption can *NOT* be cleaned up by removing just the file in question and letting it be restored by 'svn update'. The *parent* folder of the file in question must be plain-'rm -rf'd and restored by update. An entirely new checkout is also a way out of such a situation. While the WC is corrupted, any new mods on the file as well as any commit will bail with mismatching checksums. It is not possible to corrupt the repos, beyond the fact that the wrong BASE was committed by the client. In conclusion, we will not bother to fix this issue for 1.6.x. Agreed? ~Neels
signature.asc
Description: OpenPGP digital signature
