Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>> 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.
Hey, (4.) svn remove and (6.) svn delete are the same thing.
>
> 7. The user can update, but it doesn't solve the out-of-date
> problem in commit.
Still, it is unacceptable to remove a file that may have local modifications.
Two ideas:
a) How about revert or resolved?
I think this would be best solved by one of these. Since resolved should be
called when the conflict has been sorted out (resolved), I guess revert
would be the way to go.
(this is fiction:)
$ svn status
M file_incoming_delete
$ svn up
C file_incoming_delete
$ ls
file_incoming_delete
$ svn revert file_incoming_delete
D file_incoming_delete
$ ls
<no file_incoming_delete>
$ svn ci
Committed revision N+1.
b) How about delete/add --resolve?
(this is fiction:)
$ svn status
M file_incoming_delete
$ svn up
C file_incoming_delete
$ ls
file_incoming_delete
$ svn rm file_incoming_delete
<Cannot remove file_incoming_delete>
To resolve a tree-conflict, use `svn rm --resolve'.
<this message shows only in presence of a tree-conflict>
$ svn rm --resolve file_incoming_delete
D file_incoming_delete
$ ls
<no file_incoming_delete>
$ svn ci
Committed revision N+1.
(this is fiction:)
$ svn status
M file_incoming_delete
$ svn up
C file_incoming_delete
$ ls
file_incoming_delete
$ svn add file_incoming_delete
<Cannot add file_incoming_delete>
To resolve a tree-conflict, use `svn add --resolve'.
<this message shows only in presence of a tree-conflict>
$ svn add --resolve file_incoming_delete
A file_incoming_delete
$ ls
file_incoming_delete
$ svn ci
Committed revision N+1.
Isn't one or both of them worth implementing instead of the current fix? Or
what is it you're saying, Steve? ;)
~Neels
Received on 2008-11-02 01:01:22 CET