On Thu, 2009-01-22 at 17:07 +0100, Stephen Butler wrote:
> Quoting Mark Phippard <mphippard_at_collab.net>:
>
> > On Thu, Jan 22, 2009 at 9:56 AM, Julian Foad
> > <julianfoad_at_btopenworld.com> wrote:
> >> FYI I'm just about to look at this.
> >
> > I added an svn info to the script to look at the tree conflict. The
> > problem is that after running update the local revision in the WC for
> > the folder is 1 when it should have been updated to 2 by the update
> > command. So this is why it is out of date when you try to commit.
> > When the tree conflict was created it should have still allowed the WC
> > revision to be updated.
>
> Turning off the skipping of tree conflict victims is pretty
> straightforward, at least for this use case (#1 in
> notes/tree-conflicts/detection.txt).
Is it? "Turning off skipping" means "designing and implementing some
behaviour other than skipping". The local node is scheduled for
deletion. The incoming change is to modify it. I assume the existing
"update" code would not handle this case already.
The behavior we want for UC1 is: the WC should end up scheduled for
delete, but with an updated base, like it would if we reverted the local
delete, updated, and then re-did the local delete.
I am doing the corresponding thing for Use Case 2 (where the deletion is
incoming and the modification is local) in issue #3334. It is
straightforward in concept, but hard because the WC entry state
manipulations are so hard to get right.
It would be great if we can do this for Use Case 1 too. It sounds like
it is important.
> What should we do if the user runs update again without resolving the
> existing tree conflict first? Skipping is not an option.
Why is skipping not an option when there's an existing tree conflict?
Skipping is exactly what we should do when there's any existing conflict
(tree or otherwise), as per the comment I put at the top of
libsvn_wc/update_editor.c.
There are certainly better things we could aim to do, but let's get the
basic handling right before we try to allow updating a node that's
already in conflict.
- Julian
> I suppose we could record a new tree conflict, possibly overwriting
> an existing tree conflict. It could get confusing if the user
> updates and raises a tree conflict in dir A, then later updates dir
> A/B and raises a new conflict in A/B. Now there are two tree
> conflicts in the same tree. This could happen in everyday situations
> such as an interrupted update.
>
> Does anyone see a problem with overwritten or redundant tree
> conflicts?
>
> Does anyone know a better way to handle tree conflicts without
> skipping?
>
> Steve
>
> >
> > Path: wc2/A/B/E
> > URL: file:///Users/mphippard/tree-conflicts/repos/trunk/A/B/E
> > Repository Root: file:///Users/mphippard/tree-conflicts/repos
> > Repository UUID: fd889f68-59a4-4395-b512-2cc3d879576e
> > Revision: 1
> > Node Kind: directory
> > Schedule: delete
> > Last Changed Author: mphippard
> > Last Changed Rev: 1
> > Last Changed Date: 2009-01-22 10:02:16 -0500 (Thu, 22 Jan 2009)
> > Tree conflict: local delete, incoming edit upon update
> > Source left: (none)
> > file:///Users/mphippard/tree-conflicts/repos/trunk/A/B/E_at_1
> > Source right: (dir)
> > file:///Users/mphippard/tree-conflicts/repos/trunk/A/B/E_at_2
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1043309
Received on 2009-01-22 17:28:47 CET