firstname.lastname@example.org wrote on 08/11/2006 12:26:59 PM:
> > On 8/9/06, Ivan Zhakov <email@example.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
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?
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
(wc_to_wc_copy): Remove force arg. Remove check for "awkward" files
local mods and unversioned files).
(basic_copy_and_move_files, mv_unversioned_file, force_move,
copy_move_added_paths): Remove all uses of '--force' option when running
Received on Wed Aug 23 21:19:32 2006
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com