[PATCH]: Was: Make --force always switched on for svn move command

[Paul Burba <pa...@softlanding.com>]

rooneg@gmail.com wrote on 08/11/2006 12:26:59 PM:

> > On 8/9/06, Ivan Zhakov <ch...@gmail.com> wrote:
> > BTW, is anybody know reasons why we forbidd move directories with
> > unversioned files without --force option? I consider we should allow
> > this, because we are copying *all* files including unversioned at new
> > location. Might be we don't need treat this situation as dangerous and
> > perform operation without user attention?
> 
> As long as we're always copying the unversioned files, that makes sense 
to me.
> 
> -garrett

Subversion prevents unforced moves not only of unversioned paths, but also 
of locally modified paths.  Copy allows both of these cases *without* the 
--force option (actually copy doesn't support --force at all).  Removing 
the call to svn_client__can_delete() in wc_to_wc_copy() removes the 
requirement for --force.  I'm not sure why we ever did this since we are 
moving items, not truly deleting them, unlike the only other call to 
svn_client__can_delete() in svn_client__wc_delete() where such a check 
makes some sense. 

Any objections to this change?

Paul B.

P.S. There is one other consideration regarding this change: whether to 
get rid of --force entirely for svn move.  Looking at svn_client_move4() I 
don't see any reason to keep it, but I'm a bit unsure how deprecating a 
subcommand option is supposed to happen. 

[[[
Don't require --force to move dirs with unversioned files or local mods.

Yet another follow-up to r20811.  This brings svn move's behavior in line
with svn copy.

Suggested by: zhakov

* subversion/libsvn_client/copy.c
  (wc_to_wc_copy): Remove force arg.  Remove check for "awkward" files 
(i.e.
  local mods and unversioned files).

* subversion/tests/cmdline/copy_tests.py
  (basic_copy_and_move_files, mv_unversioned_file, force_move,
  move_copied_file_and_dir, move_moved_file_and_dir,
  move_file_within_moved_dir, move_file_out_of_moved_dir,
  move_dir_within_moved_dir, move_dir_out_of_moved_dir,
  move_file_back_and_forth, move_dir_back_and_forth,
  copy_move_added_paths): Remove all uses of '--force' option when running
  svn move.
]]]

Re: [PATCH]: Was: Make --force always switched on for svn move command

[Paul Burba <pa...@softlanding.com>]

Paul Burba <pa...@softlanding.com> wrote on 08/25/2006 12:48:50 PM:

> rooneg@gmail.com wrote on 08/24/2006 11:45:22 AM:
> 
> > On 8/24/06, Ivan Zhakov <ch...@gmail.com> wrote:
> > > On 8/24/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > > > On 8/23/06, Paul Burba <pa...@softlanding.com> wrote:
> > > >
> > > > > Subversion prevents unforced moves not only of unversioned 
> > paths, but also
> > > > > of locally modified paths.  Copy allows both of these cases 
> > *without* the
> > > > > --force option (actually copy doesn't support --force at all). 
> Removing
> > > > > the call to svn_client__can_delete() in wc_to_wc_copy() removes 
> the
> > > > > requirement for --force.  I'm not sure why we ever did this 
since 
> we are
> > > > > moving items, not truly deleting them, unlike the only other 
call 
> to
> > > > > svn_client__can_delete() in svn_client__wc_delete() where such a 

> check
> > > > > makes some sense.
> > > > >
> > > > > Any objections to this change?
> > > >
> > > > One potential problem that I ran across while playing with this is
> > > > that while move now carries unversioned files along with it, they
> > > > won't be put back after a revert, they're left in the unversioned
> > > > destination directory.
> > > >
> > > > Not sure if that's a showstopper or not...
> > > >
> > > Yes, after further meditation I've found the same problem. But as 
you
> > > I'm not sure if that's problem or not. Any thoughts?
> > 
> > I lean towards "not a problem", I mean as Paul pointed out when
> > talking about this on IRC, it's not like a revert of a copy will
> > remove unversioned files that it copied from another tree because it
> > knows you've got another copy someplace...
> > 
> > -garrett
> 
> Hi All,
> 
> It seems there are no objections thus far to this patch here or in IRC. 
> I'd like to commit, so if anyone has any outstanding concerns please let 

> me know.
> 
> Three things to keep in mind if you *don't* like this change:
> 
> * svn copy doesn't require force to move unversioned or locally modified 

> items.
> 
> * Like svn delete, svn move deletes unversioned/locally modified items, 
> but they are still copied somewhere else in the WC, so they are not 
really 
> gone.
> 
> * revert's behavior on moved unversioned/locally modified items is 
> unchanged, this patch is simply doing away with the need for --force to 
> make such a move in the first place.

Committed r21347.

One outstanding issue remains, should the --force option be removed for 
svn move?  It is no longer used for anything and I see no reason to 
continue supporting it.

Paul B.

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

Re: [PATCH]: Was: Make --force always switched on for svn move command

[Paul Burba <pa...@softlanding.com>]

rooneg@gmail.com wrote on 08/24/2006 11:45:22 AM:

> On 8/24/06, Ivan Zhakov <ch...@gmail.com> wrote:
> > On 8/24/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > > On 8/23/06, Paul Burba <pa...@softlanding.com> wrote:
> > >
> > > > Subversion prevents unforced moves not only of unversioned 
> paths, but also
> > > > of locally modified paths.  Copy allows both of these cases 
> *without* the
> > > > --force option (actually copy doesn't support --force at all). 
Removing
> > > > the call to svn_client__can_delete() in wc_to_wc_copy() removes 
the
> > > > requirement for --force.  I'm not sure why we ever did this since 
we are
> > > > moving items, not truly deleting them, unlike the only other call 
to
> > > > svn_client__can_delete() in svn_client__wc_delete() where such a 
check
> > > > makes some sense.
> > > >
> > > > Any objections to this change?
> > >
> > > One potential problem that I ran across while playing with this is
> > > that while move now carries unversioned files along with it, they
> > > won't be put back after a revert, they're left in the unversioned
> > > destination directory.
> > >
> > > Not sure if that's a showstopper or not...
> > >
> > Yes, after further meditation I've found the same problem. But as you
> > I'm not sure if that's problem or not. Any thoughts?
> 
> I lean towards "not a problem", I mean as Paul pointed out when
> talking about this on IRC, it's not like a revert of a copy will
> remove unversioned files that it copied from another tree because it
> knows you've got another copy someplace...
> 
> -garrett

Hi All,

It seems there are no objections thus far to this patch here or in IRC. 
I'd like to commit, so if anyone has any outstanding concerns please let 
me know.

Three things to keep in mind if you *don't* like this change:

* svn copy doesn't require force to move unversioned or locally modified 
items.

* Like svn delete, svn move deletes unversioned/locally modified items, 
but they are still copied somewhere else in the WC, so they are not really 
gone.

* revert's behavior on moved unversioned/locally modified items is 
unchanged, this patch is simply doing away with the need for --force to 
make such a move in the first place.

Oh, I almost forgot the fourth, and most important, point:

* <JOKE>It's all Ivan's idea, throw him under the bus! :-P</JOKE>

Thanks,

Paul B.

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

Re: [PATCH]: Was: Make --force always switched on for svn move command

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/24/06, Ivan Zhakov <ch...@gmail.com> wrote:
> On 8/24/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > On 8/23/06, Paul Burba <pa...@softlanding.com> wrote:
> >
> > > Subversion prevents unforced moves not only of unversioned paths, but also
> > > of locally modified paths.  Copy allows both of these cases *without* the
> > > --force option (actually copy doesn't support --force at all).  Removing
> > > the call to svn_client__can_delete() in wc_to_wc_copy() removes the
> > > requirement for --force.  I'm not sure why we ever did this since we are
> > > moving items, not truly deleting them, unlike the only other call to
> > > svn_client__can_delete() in svn_client__wc_delete() where such a check
> > > makes some sense.
> > >
> > > Any objections to this change?
> >
> > One potential problem that I ran across while playing with this is
> > that while move now carries unversioned files along with it, they
> > won't be put back after a revert, they're left in the unversioned
> > destination directory.
> >
> > Not sure if that's a showstopper or not...
> >
> Yes, after further meditation I've found the same problem. But as you
> I'm not sure if that's problem or not. Any thoughts?

I lean towards "not a problem", I mean as Paul pointed out when
talking about this on IRC, it's not like a revert of a copy will
remove unversioned files that it copied from another tree because it
knows you've got another copy someplace...

-garrett

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

Re: [PATCH]: Was: Make --force always switched on for svn move command

[Ivan Zhakov <ch...@gmail.com>]

On 8/24/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 8/23/06, Paul Burba <pa...@softlanding.com> wrote:
>
> > Subversion prevents unforced moves not only of unversioned paths, but also
> > of locally modified paths.  Copy allows both of these cases *without* the
> > --force option (actually copy doesn't support --force at all).  Removing
> > the call to svn_client__can_delete() in wc_to_wc_copy() removes the
> > requirement for --force.  I'm not sure why we ever did this since we are
> > moving items, not truly deleting them, unlike the only other call to
> > svn_client__can_delete() in svn_client__wc_delete() where such a check
> > makes some sense.
> >
> > Any objections to this change?
>
> One potential problem that I ran across while playing with this is
> that while move now carries unversioned files along with it, they
> won't be put back after a revert, they're left in the unversioned
> destination directory.
>
> Not sure if that's a showstopper or not...
>
Yes, after further meditation I've found the same problem. But as you
I'm not sure if that's problem or not. Any thoughts?

-- 
Ivan Zhakov

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

Re: [PATCH]: Was: Make --force always switched on for svn move command

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/23/06, Paul Burba <pa...@softlanding.com> wrote:

> Subversion prevents unforced moves not only of unversioned paths, but also
> of locally modified paths.  Copy allows both of these cases *without* the
> --force option (actually copy doesn't support --force at all).  Removing
> the call to svn_client__can_delete() in wc_to_wc_copy() removes the
> requirement for --force.  I'm not sure why we ever did this since we are
> moving items, not truly deleting them, unlike the only other call to
> svn_client__can_delete() in svn_client__wc_delete() where such a check
> makes some sense.
>
> Any objections to this change?

One potential problem that I ran across while playing with this is
that while move now carries unversioned files along with it, they
won't be put back after a revert, they're left in the unversioned
destination directory.

Not sure if that's a showstopper or not...

-garrett

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