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

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

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-08-24 17:45:22 CEST

On 8/24/06, Ivan Zhakov <chemodax@gmail.com> wrote:
> On 8/24/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 8/23/06, Paul Burba <paulb@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
Received on Thu Aug 24 17:48:02 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.