On Sat, 2008-11-01 at 18:44 +0100, Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
> > So, what have we found?
> >
> > * "revert" acts on the parent dir, but needs to act on a victim instead
> > for consistency.
> > - I'm fixing that.
> >
> > * "revert -R" fails to revert the whole WC,
> > - I haven't yet reproduced that.
> >
> > * Commit fails with poor error message "File not found: transaction
> > '2-3', path '/foo'" instead of "Out of date".
> > - To be investigated.
>
> Fixed in r33994. I had an old patch lying around from back in February,
> when I was hacking on the double-delete branch (since merged to trunk).
> Just needed to intercept those funky error messages in the client and
> wrap them in a more friendly "out of date" error.
Excellent. Thanks, Steve.
> > * Revert then update leads to "WC is corrupt... Attempt to add tree
> > conflict that already exists". That's possibly a bad error message: I
> > think it might mean that there's a bug in the code that's trying to
> > raise a new conflict, not that the WC is corrupt.
> > - We must change the error message to admit that it might well be a
> > bug.
> > - The cause is to be investigated.
>
> In most of the update callbacks, we don't yet check for an existing
> tree (or other) conflict before creating a fresh tree conflict.
Yes. That, I believe, is something we must fix.
> > I've started tackling the "revert must act on a victim" now, but I'm not
> > sure that is the most urgent issue, since as far as I can tell it does
> > actually work (clear tree conflict indications) if you give it the
> > parent path (or recursive).
> >
> > Steve, you just committed a change to make "update" carry out a deletion
> > while raising a tree conflict. I don't get why that's what we need. Is
> > that in keeping with a plan or is it just addressing the current
> > situation? I thought the plan was to skip any updating when we raise a
> > tree conflict, but I'm afraid I've rather lost track of the grand plan
> > through concentrating on the individual parts of it.
>
> That was the plan. Maybe we can actually do it that way. But our
> current tree conflict implementation (before r33983, the change you
> mention) can easily put the user in a situation where there is a
> tree conflict with no escape:
>
> 1. The working copy has a modified file that update wants to delete.
>
> 2. We flag a tree conflict during update and skip the deletion.
>
> 3. The user can't commit, because the file doesn't exist in the
> repository anymore.
>
> 4. The user can't svn remove the file. With --force, their mods
> will be lost. Anyway, that would lead to another kind of tree
> conflict.
>
> 5. The user can't svn add the file to reinstate it, because it's
> still under version control.
>
> 6. The user can't svn delete the file to accept the incoming
> deletion, because commit says the working copy is out of date.
>
> 7. The user can update, but it doesn't solve the out-of-date
> problem in commit.
>
> Maybe there's a clever way to work around this. I couldn't
> think of one, so I sacrificed the "skip everything" design
> principle. Allowing update to delete tree-conflicted trees
> is a very simple code change, and it solves all of the
> problems listed above. Commit (#3) is a no-op, and .
If it solves all of the problems there, there's got to be something
right!
> As I mentioned in my first reply to Mark, from the earliest
> powerpoints (issue 2282) that inspired our tree conflict effort,
> we always jumped from tree conflict detection to svn resolved
> & svn commit with a bit of hand-waving.
>
> Anyway, since r33983 I can run your tree-conflict-bug.sh script
> and it all works fine.
Thanks. At least that seems like a better state of usability from which
we can proceed.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-03 12:42:34 CET