On Tue, Mar 12, 2013 at 3:23 PM, Philip Martin
<philip.martin_at_wandisco.com>wrote:
> 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?
>
> 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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-03-12 20:37:52 CET