On Tue, Jan 8, 2013 at 7:42 AM, Stefan Sperling <stsp_at_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/
Received on 2013-01-08 14:40:51 CET