You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2011/03/06 18:38:59 UTC
RE: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py
> -----Original Message-----
> From: danielsh@apache.org [mailto:danielsh@apache.org]
> Sent: zondag 6 maart 2011 16:44
> To: commits@subversion.apache.org
> Subject: svn commit: r1078497 - in /subversion/trunk/subversion:
> libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c
> tests/cmdline/update_tests.py
>
> Author: danielsh
> Date: Sun Mar 6 15:43:34 2011
> New Revision: 1078497
>
> URL: http://svn.apache.org/viewvc?rev=1078497&view=rev
> Log:
> Fix issue #3807, "'svn up' of a nonexistent child in a copied dir triggers an
> assertion". This patch makes a couple of places treat added or absent nodes
> explicitly.
>
> It's possible that in a few of these places, the handling of added nodes
> should
> be done by svn_wc__db_read_info() rather than by its callers --- but that
> patch
> implements the handling in the callers.
>
> * subversion/libsvn_wc/update_editor.c
> (make_dir_baton):
> Scan more than the BASE tree when computing NEW_RELPATH.
> (make_editor):
> Look for REPOS_ROOT_URL and REPOS_UUID for added nodes, too.
>
> * subversion/libsvn_wc/adm_crawler.c
> (svn_wc_crawl_revisions5):
> Consider svn_wc__db_status_absent the same as
> svn_wc__db_status_not_present.
>
> * subversion/tests/cmdline/update_tests.py
> (update_nonexistent_child_of_copy): Expect it to pass.
>
> Modified:
> subversion/trunk/subversion/libsvn_wc/adm_crawler.c
> subversion/trunk/subversion/libsvn_wc/update_editor.c
> subversion/trunk/subversion/tests/cmdline/update_tests.py
>
> Modified: subversion/trunk/subversion/libsvn_wc/adm_crawler.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/adm
> _crawler.c?rev=1078497&r1=1078496&r2=1078497&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/libsvn_wc/adm_crawler.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/adm_crawler.c Sun Mar 6
> 15:43:34 2011
> @@ -786,7 +786,8 @@ svn_wc_crawl_revisions5(svn_wc_context_t
> status = svn_wc__db_status_not_present; /* As checkout */
> }
>
> - if ((status == svn_wc__db_status_not_present)
> + if (status == svn_wc__db_status_not_present
> + || status == svn_wc__db_status_absent
> || (target_kind == svn_wc__db_kind_dir
> && status != svn_wc__db_status_normal
> && status != svn_wc__db_status_incomplete))
>
> Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/upd
> ate_editor.c?rev=1078497&r1=1078496&r2=1078497&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Sun Mar 6
> 15:43:34 2011
> @@ -600,9 +600,33 @@ make_dir_baton(struct dir_baton **d_p,
> {
> /* Get the original REPOS_RELPATH. An update will not be
> changing its value. */
> - SVN_ERR(svn_wc__db_scan_base_repos(&d->new_relpath, NULL,
> NULL,
> + svn_wc__db_status_t status;
> + const char *repos_relpath, *original_repos_relpath;
> + SVN_ERR(svn_wc__db_read_info(&status, NULL, NULL,
> &repos_relpath,
> + NULL, NULL, NULL, NULL, NULL, NULL,
> + NULL, NULL, NULL, NULL, NULL,
> + &original_repos_relpath,
> + NULL, NULL, NULL, NULL, NULL, NULL,
> + NULL, NULL,
> + eb->db, d->local_abspath,
> + dir_pool, scratch_pool));
> + if (status == svn_wc__db_status_added)
> + SVN_ERR(svn_wc__db_scan_addition(NULL, NULL,
> + &repos_relpath, NULL, NULL,
> + &original_repos_relpath, NULL, NULL,
> + NULL,
> eb->db, d->local_abspath,
> dir_pool, scratch_pool));
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)
> + if (original_repos_relpath)
> + d->new_relpath = original_repos_relpath;
> + else if (repos_relpath)
> + d->new_relpath = repos_relpath;
> + else
> + SVN_ERR(svn_wc__db_scan_base_repos(&d->new_relpath, NULL,
> NULL,
> + eb->db, d->local_abspath,
> + dir_pool, scratch_pool));
> + SVN_ERR_ASSERT(d->new_relpath);
> }
> }
>
> @@ -4830,17 +4854,27 @@ make_editor(svn_revnum_t *target_revisio
> svn_delta_editor_t *tree_editor = svn_delta_default_editor(edit_pool);
> const svn_delta_editor_t *inner_editor;
> const char *repos_root, *repos_uuid;
> + svn_wc__db_status_t status;
>
> /* An unknown depth can't be sticky. */
> if (depth == svn_depth_unknown)
> depth_is_sticky = FALSE;
>
> /* Get the anchor's repository root and uuid. */
> - SVN_ERR(svn_wc__db_read_info(NULL,NULL, NULL, NULL, &repos_root,
> &repos_uuid,
> + SVN_ERR(svn_wc__db_read_info(&status, NULL, NULL, NULL,
> + &repos_root, &repos_uuid,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, wc_ctx->db, anchor_abspath,
> result_pool, scratch_pool));
> +
> + /* ### For adds, REPOS_ROOT and REPOS_UUID would be NULL now. */
> + if (status == svn_wc__db_status_added)
> + SVN_ERR(svn_wc__db_scan_addition(NULL, NULL, NULL,
> + &repos_root, &repos_uuid,
> + NULL, NULL, NULL, NULL,
> + wc_ctx->db, anchor_abspath,
> + result_pool, scratch_pool));
Only the op_depth 0 ancestor is interesting. The update editor should not look at the higher layers.
>
> /* With WC-NG we need a valid repository root */
> SVN_ERR_ASSERT(repos_root != NULL && repos_uuid != NULL);
>
> Modified: subversion/trunk/subversion/tests/cmdline/update_tests.py
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/
> update_tests.py?rev=1078497&r1=1078496&r2=1078497&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/tests/cmdline/update_tests.py (original)
> +++ subversion/trunk/subversion/tests/cmdline/update_tests.py Sun Mar 6
> 15:43:34 2011
> @@ -5346,7 +5346,6 @@ def update_with_file_lock_and_keywords_p
> # Updating a nonexistent or deleted path should be a successful no-op,
> # when there is no incoming change. In trunk@1035343, such an update
> # within a copied directory triggered an assertion failure.
> -@XFail()
> @Issue(3807)
> def update_nonexistent_child_of_copy(sbox):
> """update a nonexistent child of a copied dir"""
>
I haven't looked at this issue, but I think the expected behavior should be an error that explains why you shouldn't do this.
Updating nodes that don't exist in op_depth 0 is only valid for pulling in unexisting child nodes. In this case it would be a child a few levels down and this scenario is not supported by editor v1.
(But svn up --parents would allow it by using multiple updates)
Bert
Re: svn commit: r1078497 - in /subversion/trunk/subversion:
libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c
tests/cmdline/update_tests.py
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Mon, Mar 07, 2011 at 09:28:43 +0000:
> Daniel Shahaf <d....@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
RE: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: maandag 7 maart 2011 13:50
> To: Bert Huijben
> Cc: 'Daniel Shahaf'; dev@subversion.apache.org
> Subject: Re: svn commit: r1078497 - in /subversion/trunk/subversion:
> libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c
> tests/cmdline/update_tests.py
>
> "Bert Huijben" <be...@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.
If you say to the repository, this local path A2 represents this server path
A (via a replacement of A2 with a copy of A), you don't receive changes for
the original path A2.
So if somebody updated the file A2/gamma, you don't see that it changed...
and you don't get the changed A2/gamma.
Which hides the edit on delete/replace tree conflict.
> > 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.
Working copy at r1 with A2 deleted
svn up .
<now revision 3>
svn revert -R .
If update is implemented the WC-NG way: all updates are handled (no skips)
* Your working copy is at R2
If you implement this potential behavior
Most of your working copy is at rr, but A2 is still at r1.
So then you try to commit a change of A2 (the replacement) and you get:
Working copy out of date, please update.
And if A2 is replaced and we decide to update the added node... you can
update 100 times, but the deleted A2 is still on r2.
Update has to handle the BASE of deleted nodes, to allow committing
deletions (and properly detect tree conflicts). In 1.6 we did this mostly
non-recursive because we couldn't handle all different trees under a delete,
but with WC-NG update should always update the entire BASE tree.
Bert
Re: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@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
RE: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: maandag 7 maart 2011 10:29
> To: Daniel Shahaf
> Cc: dev@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....@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
Re: svn commit: r1078497 - in /subversion/trunk/subversion: libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c tests/cmdline/update_tests.py
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@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
Re: svn commit: r1078497 - in /subversion/trunk/subversion:
libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c
tests/cmdline/update_tests.py
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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
Bert Huijben wrote on Sun, Mar 06, 2011 at 18:38:59 +0100:
> > -----Original Message-----
> > From: danielsh@apache.org [mailto:danielsh@apache.org]
> > Sent: zondag 6 maart 2011 16:44
> > To: commits@subversion.apache.org
> > Subject: svn commit: r1078497 - in /subversion/trunk/subversion:
> > libsvn_wc/adm_crawler.c libsvn_wc/update_editor.c
> > tests/cmdline/update_tests.py
> >
> > Author: danielsh
> > Date: Sun Mar 6 15:43:34 2011
> > New Revision: 1078497
> >
> > URL: http://svn.apache.org/viewvc?rev=1078497&view=rev
> > Log:
> > Fix issue #3807, "'svn up' of a nonexistent child in a copied dir triggers an
> > assertion". This patch makes a couple of places treat added or absent nodes
> > explicitly.
> >
> > It's possible that in a few of these places, the handling of added nodes
> > should
> > be done by svn_wc__db_read_info() rather than by its callers --- but that
> > patch
> > implements the handling in the callers.
> >
> > * subversion/libsvn_wc/update_editor.c
> > (make_dir_baton):
> > Scan more than the BASE tree when computing NEW_RELPATH.
> > (make_editor):
> > Look for REPOS_ROOT_URL and REPOS_UUID for added nodes, too.
> >
> > * subversion/libsvn_wc/adm_crawler.c
> > (svn_wc_crawl_revisions5):
> > Consider svn_wc__db_status_absent the same as
> > svn_wc__db_status_not_present.
> >
> > * subversion/tests/cmdline/update_tests.py
> > (update_nonexistent_child_of_copy): Expect it to pass.
> >
> > Modified:
> > subversion/trunk/subversion/libsvn_wc/adm_crawler.c
> > subversion/trunk/subversion/libsvn_wc/update_editor.c
> > subversion/trunk/subversion/tests/cmdline/update_tests.py
> >
> > Modified: subversion/trunk/subversion/libsvn_wc/adm_crawler.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/adm
> > _crawler.c?rev=1078497&r1=1078496&r2=1078497&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_wc/adm_crawler.c (original)
> > +++ subversion/trunk/subversion/libsvn_wc/adm_crawler.c Sun Mar 6
> > 15:43:34 2011
> > @@ -786,7 +786,8 @@ svn_wc_crawl_revisions5(svn_wc_context_t
> > status = svn_wc__db_status_not_present; /* As checkout */
> > }
> >
> > - if ((status == svn_wc__db_status_not_present)
> > + if (status == svn_wc__db_status_not_present
> > + || status == svn_wc__db_status_absent
> > || (target_kind == svn_wc__db_kind_dir
> > && status != svn_wc__db_status_normal
> > && status != svn_wc__db_status_incomplete))
> >
> > Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/upd
> > ate_editor.c?rev=1078497&r1=1078496&r2=1078497&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original)
> > +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Sun Mar 6
> > 15:43:34 2011
> > @@ -600,9 +600,33 @@ make_dir_baton(struct dir_baton **d_p,
> > {
> > /* Get the original REPOS_RELPATH. An update will not be
> > changing its value. */
> > - SVN_ERR(svn_wc__db_scan_base_repos(&d->new_relpath, NULL,
> > NULL,
> > + svn_wc__db_status_t status;
> > + const char *repos_relpath, *original_repos_relpath;
> > + SVN_ERR(svn_wc__db_read_info(&status, NULL, NULL,
> > &repos_relpath,
> > + NULL, NULL, NULL, NULL, NULL, NULL,
> > + NULL, NULL, NULL, NULL, NULL,
> > + &original_repos_relpath,
> > + NULL, NULL, NULL, NULL, NULL, NULL,
> > + NULL, NULL,
> > + eb->db, d->local_abspath,
> > + dir_pool, scratch_pool));
> > + if (status == svn_wc__db_status_added)
> > + SVN_ERR(svn_wc__db_scan_addition(NULL, NULL,
> > + &repos_relpath, NULL, NULL,
> > + &original_repos_relpath, NULL, NULL,
> > + NULL,
> > eb->db, d->local_abspath,
> > dir_pool, scratch_pool));
>
> 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)
>
> > + if (original_repos_relpath)
> > + d->new_relpath = original_repos_relpath;
> > + else if (repos_relpath)
> > + d->new_relpath = repos_relpath;
> > + else
> > + SVN_ERR(svn_wc__db_scan_base_repos(&d->new_relpath, NULL,
> > NULL,
> > + eb->db, d->local_abspath,
> > + dir_pool, scratch_pool));
> > + SVN_ERR_ASSERT(d->new_relpath);
> > }
> > }
> >
> > @@ -4830,17 +4854,27 @@ make_editor(svn_revnum_t *target_revisio
> > svn_delta_editor_t *tree_editor = svn_delta_default_editor(edit_pool);
> > const svn_delta_editor_t *inner_editor;
> > const char *repos_root, *repos_uuid;
> > + svn_wc__db_status_t status;
> >
> > /* An unknown depth can't be sticky. */
> > if (depth == svn_depth_unknown)
> > depth_is_sticky = FALSE;
> >
> > /* Get the anchor's repository root and uuid. */
> > - SVN_ERR(svn_wc__db_read_info(NULL,NULL, NULL, NULL, &repos_root,
> > &repos_uuid,
> > + SVN_ERR(svn_wc__db_read_info(&status, NULL, NULL, NULL,
> > + &repos_root, &repos_uuid,
> > NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> > NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> > NULL, NULL, wc_ctx->db, anchor_abspath,
> > result_pool, scratch_pool));
> > +
> > + /* ### For adds, REPOS_ROOT and REPOS_UUID would be NULL now. */
> > + if (status == svn_wc__db_status_added)
> > + SVN_ERR(svn_wc__db_scan_addition(NULL, NULL, NULL,
> > + &repos_root, &repos_uuid,
> > + NULL, NULL, NULL, NULL,
> > + wc_ctx->db, anchor_abspath,
> > + result_pool, scratch_pool));
>
> Only the op_depth 0 ancestor is interesting. The update editor should not look at the higher layers.
>
> >
> > /* With WC-NG we need a valid repository root */
> > SVN_ERR_ASSERT(repos_root != NULL && repos_uuid != NULL);
> >
> > Modified: subversion/trunk/subversion/tests/cmdline/update_tests.py
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/
> > update_tests.py?rev=1078497&r1=1078496&r2=1078497&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/tests/cmdline/update_tests.py (original)
> > +++ subversion/trunk/subversion/tests/cmdline/update_tests.py Sun Mar 6
> > 15:43:34 2011
> > @@ -5346,7 +5346,6 @@ def update_with_file_lock_and_keywords_p
> > # Updating a nonexistent or deleted path should be a successful no-op,
> > # when there is no incoming change. In trunk@1035343, such an update
> > # within a copied directory triggered an assertion failure.
> > -@XFail()
> > @Issue(3807)
> > def update_nonexistent_child_of_copy(sbox):
> > """update a nonexistent child of a copied dir"""
> >
>
> I haven't looked at this issue, but I think the expected behavior should be an error that explains why you shouldn't do this.
>
> Updating nodes that don't exist in op_depth 0 is only valid for pulling in unexisting child nodes. In this case it would be a child a few levels down and this scenario is not supported by editor v1.
> (But svn up --parents would allow it by using multiple updates)
>
> Bert
>
>