Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
>
>
> 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.
Oops!
>
>>
>> 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
> modificationse.
At the moment, the file foo in Julian's tree-conflict-bug.sh is left
in place, unversioned, because it has local mods.
The change I made in r33983 is really just a stopgap, necessary
because we essentially broke the trunk. It would be nicer to mark
the tree conflict without removing the to-be-deleted file from
version control.
>
> 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.
I believe there is nothing to commit here. By running revert, the
user has asked svn to finish the update for this file, i.e., to get
rid of it.
I can't help feeling that revert should go "back in time", to the
BASE of the non-updated item, and not forward to the target revision
of the update. We'll have to squirrel away the target revision
somewhere, if we want revert to update to it.
>
>
> 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.
Again, commit has nothing to do here after finishing the update.
>
> (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? ;)
I like them both, in general.
Maybe we should first fix svn resolve to handle tree conflicts.
'svn add --resolve' sounds like 'svn resolve --accept theirs-full'
and 'svn del --resolve' sounds like 'svn resolve --accept mine-full',
in this case.
We may want the --resolve option for add/del anyway, even if it
duplicates svn resolve's behavior.
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-02 04:14:05 CET