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

Re: Resoving tree conflicts results in inconsistent state between two working copies of same branch

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Tue, 23 Aug 2011 19:27:19 +0200

On 08/23/2011 09:07 AM, Johan Corveleyn wrote:
> On Tue, Aug 23, 2011 at 5:13 AM, Neels J Hofmeyr <neels_at_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

Received on 2011-08-23 19:28:08 CEST

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