On Tue, Jan 08, 2013 at 08:40:19AM -0500, Mark Phippard wrote:
> 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.
Can't the intercepting code decide to ask the user to update a subtree
before refactoring it? I mean, I realise that these IDEs are also talking
to possibly many other version control systems, or just the OS, to move
stuff around, and I don't want to make Subversion any harder to support
than any of the other solutions. However, if abstractions these IDEs are
using are getting in the way of Subversion making progress, then I would
of course blame the problem on the IDEs. If they cannot support
pre-conditions for refactoring, they are simply too inflexible and
perhaps using the wrong abstractions.
Also, it seems that Eclipse could gain an advantage anyway by switching to
a model that encourages a single sparse working copy for all projects that
share the same repository. The user won't notice a difference, and many
operations will be faster (e.g. update/switch with serf won't have to
get the same files twice).
> 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.
In my experience, IDE users have the most amount of trouble resolving tree
conflicts. They are often shielded so much from how Subversion operates
they they simply cannot understand what's going on. It is these users
who would benefit the most from getting proper interactive conflict
resolution for tree conflicts.
Perhaps we should provide a way for 1.8 API users to suppress move
tracking. That would allow IDE developers to perform a smooth migration
to 1.8, and enable move-tracking only once they've had time to adjust
other parts of their system as necessary (e.g. by moving to a single-WC
by default first).
> 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.
That should be fine. We only require the move source subtree to be
single-rev. The rest of the working copy can be mixed-rev.
> Hope this helps explain the use case.
Thanks, yes, it does!
Received on 2013-01-08 14:58:28 CET