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

Re: svn_client_move7 and mixed-revisions

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 12 Mar 2013 19:23:53 +0000

Mark Phippard <markphip_at_gmail.com> writes:

> On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato <cmpilato_at_collab.net>wrote:
>> On 03/12/2013 02:14 PM, Philip Martin wrote:
>> > Philip Martin <philip.martin_at_wandisco.com> writes:
>> >
>> >> Yes, I believe removing allow_mixed_revisions is the solution.
>> >
>> > Eek! It's propagated further than I realised:
>> >
>> > $ svn move --help
>> > ...
>> > --allow-mixed-revisions : Allow operation on mixed-revision working
>> copy.
>> > Use of this option is not recommended!
>> > Please run 'svn update' instead.
>> >
>> > Is the legacy copy+delete without move tracking something users really
>> > want?
>> Can they still get the legacy behavior by issuing explicit 'svn copy' and
>> 'svn delete' commands? If so, might that not be enough of a workaround for
>> those that want this behavior?


> If you want to do that to command line users, it is up to you.
> As an API consumer, I would be pissed if this is a requirement. IDE users
> in particular rarely have working copies that are not mixed revision as the
> GUI's tend to steer you in that direction. It is obviously easy to just
> update the root of your working copy in a GUI, but when you have a
> graphical tool showing you changed files from the repository, a lot of
> people use those options too. And those pretty much have to only update
> the items you select. Some GUI users seem to live in that mode of
> operating.

I don't understand this. You seem to be asking for move tracking to be
unreliable in order to avoid a message that tells users how to make move
work. When the user moves things around some of the 'moves' will show
up as moves and others will not. How is that sensible? How is the user
supposed to understand what is happening?

I assume that you already handle errors from the move API. Why is this
new error not acceptable?

Certified & Supported Apache Subversion Downloads:
Received on 2013-03-12 20:24:38 CET

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.