On 12.03.2013 20:37, Mark Phippard wrote:
> On Tue, Mar 12, 2013 at 3:23 PM, Philip Martin
> <philip.martin_at_wandisco.com <mailto:philip.martin_at_wandisco.com>> wrote:
>
> Mark Phippard <markphip_at_gmail.com <mailto:markphip_at_gmail.com>> writes:
>
> > On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato
> <cmpilato_at_collab.net <mailto:cmpilato_at_collab.net>>wrote:
> >
> >> On 03/12/2013 02:14 PM, Philip Martin wrote:
> >> > Philip Martin <philip.martin_at_wandisco.com
> <mailto: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?
>
> Yes.
>
> > 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.
>
>
> I do not think users care about move tracking in this context.
> Suppose you are in a GUI tool and you are dragging and dropping a
> file from one folder to another. More than anything, I think they
> just expect this action to succeed. In my case, inside Eclipse, we do
> not get a chance to even get involved in this operation until very
> late in the process. I *think* we can still block the move, but the
> user experience is not that good. And what are we supposed to tell
> the user?
>
> As Bert has mentioned, another common place for this is refactoring.
> A user is using the tools for their language and doing some action
> that causes files or folders to be renamed as part of that process.
> Having the version control constantly complaining and blocking them
> just gives us a bad name.
>
> Does the user ideally want the best of all worlds here? Of course. I
> am sure if asked they would want all the proper move tracking in place.
>
>
> 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?
>
>
> What error message do you think we can provide that a user is going to
> understand? Have you ever known users to understand mixed-revision
> working copies? It does not help that SVN does absolutely nothing to
> help the user out. A single user working alone does a commit and
> their working copy is mixed revision. If you are the user, why would
> you expect that you need to run update after a commit when you know
> you are the one and only user working on the repository?
>
> On the other side of this, is the Enterprise users that will be forced
> to run update when they want to move or rename something, and update
> is going to possibly pull in changes they are not ready to review or
> receive.
I have to agree with Mark. As long as we don't know how to track a
mixed-revision move in all cases, then it's better to revert to
copy+delete than to block the move. Ideally only for those parts of the
move source that are actually out of date with regard to the repository,
but I take it we haven't got that far yet.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2013-03-12 20:44:55 CET