> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: maandag 7 maart 2011 10:29
> To: Daniel Shahaf
> Cc: dev_at_subversion.apache.org; Bert Huijben
> Subject: Re: svn commit: r1078497 - in /subversion/trunk/subversion:
> libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c
> tests/cmdline/update_tests.py
>
> 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.
Well, it is an essential feature of tree conflict detection. 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.
> 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.
> >> 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.)
Bert
>
> --
> Philip
Received on 2011-03-07 13:15:08 CET