"Bert Huijben" <bert_at_qqmail.nl> writes:
>> > Some scenarios:
>> >
>> > % svn cp A A2; svn up A2/
>> >
>> > % svn cp A A2; svn up A2/mu
>> >
>> > % svn rm A2; svn cp A A2; svn up A2/
>> >
>> > % svn rm A2; svn cp A A2; cd A2; svn up
>> >
>> > % svn rm A2; svn cp A A2; cd A2; svn up mu
>>
>> At present the copyfrom revision of A2 is fixed at the time of the copy.
>> Updating a copy, or inside a copy, could be useful if the copy is
>> incomplete; it could be "resume an interrupted copy". It's debateable
>> whether this should be part of update or copy.
>>
>> It's also possible that update could "see through" the copy and update
>> any deleted base nodes below, but that is of limited use to the user.
>
> Well, it is an essential feature of tree conflict detection.
Detection? Do you mean resolution? I don't really understand what you
mean.
> And you need it
> to allow revert to bring your working copy back to a pristine single
> revision working copy. I wouldn't call that limited use.
I don't understand that either.
>> A more interesting feature would be a dynamic HEAD copy, where the
>> copyfrom revision is not fixed at the time of the copy. Then update of
>> the copy would be a real operation that modified the WORKING layer.
>
> I think this should be handled as part of real moves, but in that case it
> (w/c)ould be handled via the tree conflict on the moved_away node.
I don't really understand this either. If I were to copy HEAD it might
not even be part of a move.
>> >> The update editor should not look at layers above op_depth 0. Nodes
>> >> can only be added below an existing op_depth 0 node.
>> >>
>> >> If the update editor would touch something in the higher layers just
>> >> a (tree) conflict should be raised. (And in some specific cases
>> >> things might be automatically handled for compatibility reasons)
>>
>> One case where update affects the working layer is where the update adds
>> a new node to a deleted directory. The code doesn't raise a tree
>> conflict but extends the delete to cover the new node.
>
> We discussed this a few months ago, where we finally came to the conclusion
> that the update editor should raise a tree conflict here, but the default
> tree conflict handler should then detect this case and do the right thing,
> probably without asking the user. (That way advanced clients can use a
> different method.)
I don't understand this either. The tree conflict resolution is built
into the update editor. I wasn't aware that a client using the update
editor chose the tree conflict handler.
I feel that update should always update all the BASE nodes. The old
system where bits of the BASE tree got skipped in tree conflicts is no
longer needed.
--
Philip
Received on 2011-03-07 13:50:43 CET