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

[PATCH] Was: Extending new update --force switch to handle local additions

From: Paul Burba <paulb_at_softlanding.com>
Date: 2006-09-13 22:24:59 CEST

Julian Foad <julianfoad@btopenworld.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
add
> > 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
on
> > his working copy and it fails because he still has the new files in
his
> > working copy. He feels that update should handle this.
>
> Yes, and more. Since we automatically resolve text modifications when
the
> local change is identical to the repository change, I say we ought to
> automatically resolve identical tree operations - add/delete/move
file/dir.

Hi Julian,

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
A \home\BURBA\wcs\greek\A
A \home\BURBA\wcs\greek\A\B
A \home\BURBA\wcs\greek\A\B\lambda
A \home\BURBA\wcs\greek\A\B\E
A \home\BURBA\wcs\greek\A\B\E\alpha
A \home\BURBA\wcs\greek\A\B\E\beta
A \home\BURBA\wcs\greek\A\B\F
A \home\BURBA\wcs\greek\A\mu
A \home\BURBA\wcs\greek\A\C
A \home\BURBA\wcs\greek\A\D
A \home\BURBA\wcs\greek\A\D\gamma
A \home\BURBA\wcs\greek\A\D\G
A \home\BURBA\wcs\greek\A\D\G\pi
A \home\BURBA\wcs\greek\A\D\G\rho
A \home\BURBA\wcs\greek\A\D\G\tau
A \home\BURBA\wcs\greek\A\D\H
A \home\BURBA\wcs\greek\A\D\H\chi
A \home\BURBA\wcs\greek\A\D\H\omega
A \home\BURBA\wcs\greek\A\D\H\psi
Checked out revision 1.

svn cp -m "" file:///home/burba/repos/greek/A/D/G
file:///home/burba/repos/greek/I

Committed revision 2.

svn cp \home\burba\wcs\greek\A\D\H \home\burba\wcs\greek\I
A \home\BURBA\wcs\greek\I

If we now updated \home\burba\wcs\greek what would you see the appropriate
behavior as?
 
> > Paul Burba's recent patch added --force option to update. If the file
was
> > 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
scheduled
> > add in his working copy.
>
> It shouldn't need "force".

Agreed.

> 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
conflict.

> Is there any possible
> difficulty with this? (There is the chance that this is not the
semantically
> correct merge in some cases, but that applies equally to text changes
and to
> 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
far.

If anyone has suggestions, corrections, rants, raves, reviews, etc.,
please let me know, thanks,

Paul B.
 
[[[
Enable up/sw/co to tolerate obstructions scheduled for addition without
history.

It's no longer an error when an update, switch, or checkout attempts to
add a
path that is already scheduled for addition *without* history in the WC.

In the case of dirs, the directory is tolerated and reported as
'E'xisting.

For files, if the obstruction is identical to the addition from the repos
it
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.

* subversion/libsvn_wc/update_editor.c
  (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
from
  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
addition
  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
when
  obstruction is added w/o history. Report the file as 'E'xisting if the
  merge didn't conflict.

* subversion/tests/cmdline/checkout_tests.py
  (forced_checkout_with_versioned_obstruction): Tweak expected error
message
  to reflect changes in add_or_open_file.
  (co_with_obstructing_local_adds): New test.
  (test_list): Run new test.

* subversion/tests/cmdline/switch_tests.py
  (forced_switch_failures): Tweak expected error to reflect new error
message.
  (switch_with_obstructing_local_adds): New test.
  (test_list): Run new test.

* subversion/tests/cmdline/update_tests.py
  (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.
]]]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Wed Sep 13 22:25:27 2006

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.