On 12.03.2013 20:37, Mark Phippard wrote: > On Tue, Mar 12, 2013 at 3:23 PM, Philip Martin > <philip.mar...@wandisco.com <mailto:philip.mar...@wandisco.com>> wrote: > > Mark Phippard <markp...@gmail.com <mailto:markp...@gmail.com>> writes: > > > On Tue, Mar 12, 2013 at 2:55 PM, C. Michael Pilato > <cmpil...@collab.net <mailto:cmpil...@collab.net>>wrote: > > > >> On 03/12/2013 02:14 PM, Philip Martin wrote: > >> > Philip Martin <philip.mar...@wandisco.com > <mailto:philip.mar...@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
