On Tue, Jan 8, 2013 at 8:57 AM, Stefan Sperling <stsp_at_apache.org> wrote:
> 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?
The best answer I can give right now is "I do not think so".
Generally the SCM plugins register callbacks that the IDE calls when
it wants to. It is possible there are some non-SCM specific callbacks
for refactoring pre-checks. I would have to look. I know they are
not part of the SCM API.
Keep in mind that with tree structure changes, the user action is
often something like a drag and drop. So the ability to get involved
before this happens is fairly impossible. The dialog-based
refactorings would be the more likely place where something could be
done.
In terms of your update comment, I have not followed this feature too
much. What are the potential requirements? Does the entire working
copy have to be a single revision ( that would be nigh-impossible to
automate ). Or is the issue only when moving a folder that the folder
and its children have to be a single revision?
> 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).
There are ways that intelligent users can do this, I think it is a lot
to ask of the IDE itself. Many Java users have moved to Maven and it
provides a project structure that helps in this area (thought it
introduces other complications).
> 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.
I think all users have trouble resolving tree conflicts. I think IDE
users do more refactoring which leads to more 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).
I do not believe the latter will ever happen and it is not like there
is an API or way to discover it. Just as SVN has trouble with this,
so would an IDE plugin. How are we going to know what the user plans
to do in the future in terms of whether it makes sense for them to
have multiple WC or not?
> 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.
OK, that answers previous question I had.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2013-01-08 15:20:45 CET