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.
>
> * 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.
>
>
> 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 .
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.
Regards,
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
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-01 18:45:14 CET