[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 7 Mar 2011 14:27:06 +0200

Philip Martin wrote on Mon, Mar 07, 2011 at 09:28:43 +0000:
> 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.

And even within a "fixed copyfrom revision" setting, 'svn up mu' might
be interpreted as "update mu to its copyfrom revision" --- which is
a no-op. (except when mu had been /bin/rm'd earlier)

> 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 13:30:46 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.