Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> On IRC, Bert and I were in disagreement as to how 'svn up' should behave
> in intersection with locally-added trees: whether 'update' should always
> affect the BASE tree (irrespective of any locally-replaced trees), or
> whether it should be interpreted as applying to the overlaying tree
> (i.e., the higher op_depth).
>
> Another point that Bert raised was whether 'svn up addeddir' and 'svn up
> addeddir/some/child' should both work, in light of the semantics (i.e.,
> invalidity) of rooting an update editor at an added path.
>
>
> 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.
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.
>> 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.
--
Philip
Received on 2011-03-07 10:36:06 CET