On Tue, Jan 8, 2013 at 7:42 AM, Stefan Sperling <s...@apache.org> wrote: > On Tue, Jan 08, 2013 at 01:22:42PM +0100, Johan Corveleyn wrote: >> Then let's say +0. I'd like it even better if this could be handled >> correctly with move-tracking, but I can't help in any meaningful way >> myself with that (and I rather agree that we shouldn't postpone >> releasing for too long, and keep nice things from our users), so I'll >> thankfully accept any working solution you guys (anyone) can implement >> in a reasonable timeframe :-). > > What do you hope to achieve, in terms of practical use cases, by > tracking moves across disjoint working copies? > > Do you want to enforce that both working copies need to be committed > together, so that the move happens as a copy+delete in a single revision?
Disjoint working copies are kind of the norm for IDE users, at least Eclipse. Unfortunately since it is the IDE that is kind of creating this situation it is not necessarily obvious to the user that there is anything "special" about what they are doing or anything that should be working about. If I have a large Java application, odds are pretty good that I will have several projects for different libraries that make up my application, and perhaps separate projects for the UI and business logic layers. So maybe I want to use the refactoring tools of the IDE to move some logic from business logic tier into one of my libraries so that I can use it in another of my applications. In the IDE, this is just a simple refactoring menu option, under the covers the SVN plugin has to intercept what the IDE is doing and execute svn move. If that command is going to fail, the user is going to get frustrated and not really understand why. I do not think users will generally care if SVN handles this as copy + delete. The move tracking feature would be nice, but I would rather have the command complete successfully if that is the choice. Smart Eclipse users that understand all of this have means available to create a single working copy and then "Import" those projects to the IDE. However, these users are almost always going to have mixed revisions in their working copy because the parent folders in the working copy do not appear in their IDE and will never be updated by their normal SVN actions like update. So the part of the project that is in the iDE might be at a single revision, but its parent folders in the underlying working copy will typically not be at the same revision. Hope this helps explain the use case. -- Thanks Mark Phippard http://markphip.blogspot.com/
