> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: maandag 7 maart 2011 13:50
> To: Bert Huijben
> Cc: 'Daniel Shahaf'; dev_at_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" <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.
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
Received on 2011-03-07 14:32:04 CET