On Wed, Oct 29, 2008 at 9:38 PM, Neels J. Hofmeyr <neels_at_elego.de> wrote:
>> 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".
I am not sure I agree, but ultimately it just depends on what "tools"
we are going to give the user. For example, I'd be OK with using
revert to go back to the normal state if I could then run svn update
to have it be deleted. This does not happen though as the WC seems to
think it is up to date.
I think the current behavior is wrong because there are only two
things that a user can want to do here. They either want the file to
remain, in which case they are going to need to add the file again, or
they want the file gone. Since the WC thinks this is a normal
versioned file you cannot do either. You are basically just stuck in
"no-mans" land.
> 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.
Actually I do not think the fact that my changes were copied to the
new file are all that relevant. It was nice that it happened but it
was just "luck" that I picked an example where this happened. There
is no need to focus on this as I do not believe it added anything to
the process that we need to take special account of. Maybe with the
possible exception that I suppose this is a case where we could
theoretically have "auto-resolved" the conflict and not even raised
it. I know people feel strongly on both sides of that issue and we
can cross that bridge when we have more situations where we are
capable of auto-resolving the conflicts.
>> 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...
What do you mean by "two different bases"? It sounds like you are
just describing a mixed revision working copy. The bottom line is
that the file is gone from the repository -- whether the user likes it
or not. I do not think we are doing the user any favors by pretending
the file is still versioned when it isn't. If we are going to do
this, we ought to at least have the entries file of the parent folder
understand that it has the older revision of this file so that I can
do a revert and update to delete it.
>> 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.
For a user to want or expect that behavior would seem that they would
have to just ignore what an update command does. If I run update does
it update or not? If it does, then the file ought to reflect the
state of the repository -- unversioned. Of course perhaps we need to
invent a new "state" for this scenario, but if we have to choose from
our existing states I think unversioned is the one that reflects the
reality of the situation. It also puts the working copy in the best
place to resolve the conflict as the user can run svn add or "rm" to
put the WC into the desired state. In this scenario, it probably
makes sense for the parent folder to be in the tree conflict state?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-30 03:30:23 CET