Action to lock a whole Folder about subclipse HOT 2 OPEN

We generally adhere to the SVN API. This case is kind of borderline in that there are obviously scenarios where as a GUI client we string together many API calls to build functionality, in this case it is kind of going a bit against the spirit of the feature as it is currently implemented in that the API is not well suited for this. There have been discussions of building a recursive lock/unlock of files into the API but it has not been implemented yet in SVN.

Until there is better API support we probably will not implement this feature, but I would not be against someone contributing the feature if they really want it. Since a user might just assume they can lock a folder and not realize the "details" and the performance impact that is about to happen, I do think any implementation needs to make this clear. At minimum it should be some kind of warning/confirmation dialog though I think a better implementation would be to build a dialog that shows all the files that will be locked and perhaps even give some UI to fine-tune the list once the user can see it. This would probably make it more clear that all of those file locks will be obtained though even then I am not sure the user will really appreciate the client/server traffic that will have to take place.

You should also note that the lock API available to us can only be run against a working copy ... the locks are obtained from and stored on the server but we cannot do locks against a URL. Without API support this is for the best anyway since the recursive list API call that would be needed to get the files from the server is also a fairly expensive API call on some repositories.

from subclipse.

Ok, it's up to you to implement it or not. I just think that it could be a
good feature as I saw it on the Eclipse Subversive plugin. It shows a
dialog with all the files being locked. Then you can agree and continue the
locking or not.

El 15 sept. 2016 21:21, "Mark Phippard" [email protected] escribió:

We generally adhere to the SVN API. This case is kind of borderline in
that there are obviously scenarios where as a GUI client we string together
many API calls to build functionality, in this case it is kind of going a
bit against the spirit of the feature as it is currently implemented in
that the API is not well suited for this. There have been discussions of
building a recursive lock/unlock of files into the API but it has not been
implemented yet in SVN.

Until there is better API support we probably will not implement this
feature, but I would not be against someone contributing the feature if
they really want it. Since a user might just assume they can lock a folder
and not realize the "details" and the performance impact that is about to
happen, I do think any implementation needs to make this clear. At minimum
it should be some kind of warning/confirmation dialog though I think a
better implementation would be to build a dialog that shows all the files
that will be locked and perhaps even give some UI to fine-tune the list
once the user can see it. This would probably make it more clear that all
of those file locks will be obtained though even then I am not sure the
user will really appreciate the client/server traffic that will have to
take place.

You should also note that the lock API available to us can only be run
against a working copy ... the locks are obtained from and stored on the
server but we cannot do locks against a URL. Without API support this is
for the best anyway since the recursive list API call that would be needed
to get the files from the server is also a fairly expensive API call on
some repositories.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEdqM-mbPGo5Zv-3PSLBr6f7emWvB0w1ks5qqZrOgaJpZM4J94y2
.

from subclipse.