Julian Foad <email@example.com> wrote on 08/23/2006 07:04:02 PM:
> Mark Phippard wrote:
> > The scenario is that the user contributed a patch to an open source
> > project using Subversion. The patch included new files, so he ran svn
> > so that they would be included in the svn diff output. The patch is
> > accepted and committed by a committer. The user now runs svn update
> > his working copy and it fails because he still has the new files in
> > working copy. He feels that update should handle this.
> Yes, and more. Since we automatically resolve text modifications when
> local change is identical to the repository change, I say we ought to
> automatically resolve identical tree operations - add/delete/move
I don't understand what you mean regarding deletes. It seems that
Subversion already handles deletes, both scheduled in the WC or coming
from the REPOS during an update, switch, or checkout. Was there a
specific scenario you had in mind where it doesn't do what you want?
Regarding moves (and copies): A WC->WC move or copy results in a path
scheduled for addition with history. If this path obstructs an addition
or deletion from the repository during an up/sw/co wouldn't we want to
simply prevent that outright? If we do allow it, what would the expected
behavior be? For example:
svn co file:///home/burba/repos/greek \home\burba\wcs\greek
Checked out revision 1.
svn cp -m "" file:///home/burba/repos/greek/A/D/G
Committed revision 2.
svn cp \home\burba\wcs\greek\A\D\H \home\burba\wcs\greek\I
If we now updated \home\burba\wcs\greek what would you see the appropriate
> > Paul Burba's recent patch added --force option to update. If the file
> > in an unversioned status in his working copy, and he used this option,
> > then update would handle the situation. I think we should consider
> > extending this feature to do the same thing if the file was a
> > add in his working copy.
> It shouldn't need "force".
> It should just be part of our normal
> behaviour that
> we merge identical changes in the obvious trivial way.
In this patch I've interpreted the "obvious trivial way" to mean:
* An obstructing directory scheduled for addition without history is
simply tolerated and reported as 'E'xisting.
* An obstructing file scheduled for addition without history is merged
with the file coming from the repos. But since the text-base for the WC
file is empty (it's really not under version control yet despite having a
record in entires) we are merging the diff between an empty file and the
WC file and an empty file and the REPOS file. This means that the only
possible outcomes are identical files (again reported with 'E'xists) or a
> Is there any possible
> difficulty with this? (There is the chance that this is not the
> correct merge in some cases, but that applies equally to text changes
> tree changes.)
A patch to tolerate local additions, within the limitations described
above, is attached. There is one thing left undone: prop merges, I'm
working on that now, but I want to get some thoughts on my approach so
If anyone has suggestions, corrections, rants, raves, reviews, etc.,
please let me know, thanks,
Enable up/sw/co to tolerate obstructions scheduled for addition without
It's no longer an error when an update, switch, or checkout attempts to
path that is already scheduled for addition *without* history in the WC.
In the case of dirs, the directory is tolerated and reported as
For files, if the obstruction is identical to the addition from the repos
is reported as 'E'xisting, if it differs it's treated as a conflict.
Obstructions scheduled for addition with history still result in an error.
(file_baton): New member add_existed.
(make_file_baton): Initialize new file_baton member.
(prep_directory): Retrieve *svn_wc_adm_access_t if attempt to open it
fails due to locked WC.
(add_directory): Revamp tests of valid obstructions to add coming from
repos to allow obstructions scheduled for addition without history.
If dir is scheduled for addition without history, change the schedule in
its parent and its own "this dir" entry to normal. Also change the
"this dir" rev from 0 to the target revision. And lastly, use the
'E'xists notification for obstructing adds without history.
(add_or_open_file): Revamp tests of valid obstructions to add coming
repos to allow obstructions scheduled for addition without history. Set
new file_baton member to true if appropriate.
(merge_file): New argument 'add_existed'. If file is scheduled for
without history, change its entry schedule to normal and create an empty
text-base for it. Update the "matrix" and change it's implementation so
obstructions scheduled for addition w/o history are merged.
(close_file): Pass new file_baton member to merge_file() so it knows
obstruction is added w/o history. Report the file as 'E'xisting if the
merge didn't conflict.
(forced_checkout_with_versioned_obstruction): Tweak expected error
to reflect changes in add_or_open_file.
(co_with_obstructing_local_adds): New test.
(test_list): Run new test.
(forced_switch_failures): Tweak expected error to reflect new error
(switch_with_obstructing_local_adds): New test.
(test_list): Run new test.
(update_receive_illegal_name, forced_update_failures): Tweak expected
errors to reflect new error messages.
(update_with_obstructing_additions): New test.
(test_list): Run new test.
Received on Wed Sep 13 22:25:27 2006
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com