Re: Tree conflict bug?

Mark Phippard wrote:
> On Wed, Oct 29, 2008 at 12:38 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> On Wed, Oct 29, 2008 at 11:58:45AM -0400, Mark Phippard wrote:
>>> Using current trunk. I am doing some basic testing so I can figure
>>> out JavaHL changes to make around the status/info reporting etc.
>>>
>>> I renamed a file and committed it.
>> So you renamed ColorManager.java to MyColorManager.java, is it?
>
> Yes.
>
>>> In second WC, I made some edits to file and then did update. This
>>> reported the tree conflict. I saw stuff like this:
>>>
>>> $ svn st
>>> M C trunk/src/com/acme/ui/editors/ColorManager.java
>>> M trunk/src/com/acme/ui/editors/MyColorManager.java
>>>
[...]
> Well there are two issues. The repository has already decided this
> file does not exist any more. So if I want the file, I will have to
> svn add it. But the current status of the file in the WC would make
> this hard to know. In my case, I decided that I want my changes in
> the new file, so I want it go away.

All the while that I am fixing tree-conflicts issues, I am thinking
differently than that. I see it so that my working copy is at first hooked
to its base. So then I run `svn update', pulling in changes, and the working
copy's base is adapted. But when a tree-conflict occurs, the single safe
thing to do is Nothing At All. So those nodes that encounter tree-conflicts
remain untouched, their base remains the old one before the update.

Your case, specifically: You pulled in a delete on a locally modified file.
You get a tree-conflict. In my understanding, the working copy should still
have a locally modified, versioned file, as in the base before the update.
So I don't see it as "the repository has decided that this file should be
gone", but I see it like "at the point in the repository history we are
still at, which may be a past revision, the file is still there".

Now, IIUC, the "special" behaviour where the local modifications are
actually moved to the new file is probably clashing with the tree-conflicts
guideline. Some other code moves the local mods somewhere else, but
tree-conflicts code is in tendency desperate to do Nothing At All. So you
got, am I right, a file whose local mods went where they should (to the move
destination), but the original file was left hanging there, versioned and all?

It needs to be un-clashed.

>>> In my example, the edits I made to this file were
>>> actually automatically transferred to the new file ... Cool!.
>> Wow, I wish I knew why :)

Yeah, Steve, explain :)

>> Well, the theory goes like this:
>>
>> First, you think about what you want the merge result to be.
>>
>> Then, you make the neccessary changes to your conflicted state
>> to achieve this result and run 'svn resolved' on the tree-conflicted
>> file (currently, you may still have to run 'svn resolved' on the file's
>> parent directory instead of the file itself, I'm not sure whether we've
>> fixed this yet).
>
> I am OK with that (although I have not yet figured out how to do it.
> I do think we need to make revert pick some default "resolved"
> equivalent. Either that or do not let revert run at all.

I would expect "revert" to bring the file in question back to the base
*before* the update that encountered a conflict on it. Let's unroll this a
little:

Wow, another box of complexity opens up on me: Text and prop conflicts are
handled so that the modifications are somehow pulled in, the base is now the
new one (that was updated to) everywhere, and there are local mods that show
both sides of a (plain) conflict. Am I right?
In contrast, tree-conflicts code is in my sense *preventing the update*. But
it does that only for those files that are tree-conflicted. I don't see how
we can change that, because you can't just pull in changes in the presence
of tree-conflicts: in many cases there simply is no place to put both sides
of a conflict at. Plus, I wouldn't know how to present both sides of a
tree-conflict in the form of local mods on the working copy.

Ok, so tree-conflicts do need to skip the update. Hence, the base stays the
old one, hence revert will restore the old base.

Is it tolerable that tree-conflicts cause the working copy to be at
different bases at different nodes? Should the whole update be prevented
completely? My immediate intuition says: no way. I want to see what the new
state is, so that I can mend my conflicts into it.

So I guess that's it: in the presence of tree-conflicts, there *will* be two
different bases scattered around the working copy: conflicted nodes are at
the old base, non-conflicted ones were updated as usual.

This might just be a concept that many people may find very difficult to
grasp; that the update is finished as far as most nodes are concerned, but
was prevented to happen on the tree-conflicted nodes. It's half an update.

Please tell me I'm wrong...

>>
>>> My expectation was that svn revert would leave the file in the WC in
>>> an Unversioned status.
>> Because your initial expectation was also that the file would be
>> unversioned? I'm not saying this expectation was wrong, but we
>> need to agree upon what would be the best thing to do here.
>
> Well, since I know the file does not exist in the repository any more.
> The only valid states I can see for this file would be Scheduled add
> or Unversioned. Since I ran Revert, I'd expect it to become
> unversioned.

Just re-iterating: When you run Revert, I'd expect it to become the reverted
state before the tree-conflict, i.e. the old base without local mods. Which
is kind of not what sentient users might expect at all.

~Neels