On Thu, 2009-01-22 at 11:30 -0500, Mark Phippard wrote:
> On Thu, Jan 22, 2009 at 11:28 AM, Julian Foad
> <julianfoad_at_btopenworld.com> wrote:
> > 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.
> That is exactly what 1.5.5 does. The base is updated, you can revert
> etc. That said, I did not test this exhaustively, but that is what it
> seemed to do to me.
Oh, OK. That would make it really easy to implement the way we want it.
Great. I'll have a go if Stephen doesn't beat me to it.
> > 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.
> I had the same thought, but since Stephen said it was not an option
> and I do not know the details too well, I did not suggest it.
Received on 2009-01-22 17:38:43 CET