Page 6 of 7 FirstFirst ... 4 5 6 7 LastLast
Results 51 to 60 of 70

Thread: Not a bug - not a script problem - sourceforge issues

  1. #51

    Default

    Interestingly, the reason I have always refused to enable automatic updating of all scripts every day is that it seemed like wasteful server hits for sourceforge/github/whoever to deal with, when plenty of scripts are never updated. I see why script writers would want to be sure that script users are regularly updating, but I can also understand why sourceforge would specifically not want this type of thing from random users.

  2. #52
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,198

    Default

    I am still surrounded by shiny objects.

    I have reached out to the SF engineer who worked the ticket in case he has other suggestions.

    Introducing a delay between requests will definitely help. I'm OK with doing that, especially if the delay can be tweaked by the user. I will work on that momentarily.

    Limiting the maximum number of simultaneous requests might also get done although I have not dug deeply into how I would do that.

    I've done some playing with replacing https: with svn: I deleted a script and then checked it out with svn: It worked but the SVN version on disk is older than what my copy of TorotiseSVN wants to deal with and I'd like to understand why before I go too far.

    I note that svn is Read Only and svn+ssh will commit. If all KoLmafia SVN operations on a "project" must use the same URL then changing the URL to svn might break KoLmafia's ability to commit. On the other hand a commit will require a user name and password and I don't know if/where KoLmafia is getting those so... Still more questions than answers.

  3. #53
    Developer
    Join Date
    Aug 2009
    Posts
    2,821

    Default

    I've done some playing with replacing https: with svn: I deleted a script and then checked it out with svn: It worked but the SVN version on disk is older than what my copy of TorotiseSVN wants to deal with and I'd like to understand why before I go too far.
    Originally Posted by fronobulax View Post
    SVNKit probably needs updating :/

  4. #54
    Developer
    Join Date
    Aug 2009
    Posts
    2,821

    Default

    Actually, looks like you could probably just svn upgrade those, and it'd probably work just fine. Unless your version of SVN is sufficiently ahead of the version of SVNKit currently bundled with Mafia.

  5. #55
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,198

    Default

    SVNKit probably needs updating :/
    Originally Posted by heeheehee View Post
    Quite possibly. There is a new version circa May 2018 but I am not quite ready to look at the differences and incorporate it. Neither am I willing to change the build process to maven or something similar where we can just grab a jar file as a third party dependency. And I just noticed mafia uses some third party jars so maybe that is the way forward.
    You just vehemently agreed with me
    Originally Posted by Veracity View Post
    I agree with frono.
    Originally Posted by Veracity View Post

  6. #56
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,198

    Default

    Actually, looks like you could probably just svn upgrade those, and it'd probably work just fine. Unless your version of SVN is sufficiently ahead of the version of SVNKit currently bundled with Mafia.
    Originally Posted by heeheehee View Post
    I think I saw this before and Tortoise upgraded and mafia could handle it but I'm not in a position to try something and have it breal everything. Eventually...
    You just vehemently agreed with me
    Originally Posted by Veracity View Post
    I agree with frono.
    Originally Posted by Veracity View Post

  7. #57
    Senior Member
    Join Date
    Apr 2009
    Posts
    1,821

    Default

    SVNKit probably needs updating :/
    Originally Posted by heeheehee View Post
    That won't automatically upgrade the (local on-disk) repositories. Do we want a command for that, or an auto-upgrade somewhere?

  8. #58
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,198

    Default

    OK.

    I saw several 429 errors this morning so Sourceforge may be reporting a useful error message.

    I decided the easiest thing was to use a ThreadPool to limit the requests. The attached patch does that and has worked for me. If anyone feels like reviewing it or trying it, please do so. I am especially concerned that I am swallowing errors that were at least reported before.

    The pool size is set by the global variable svnThreadPoolSize. I don't expect users to really be messing with it so have not added it to a GUI.

    I'll fix the extra space before a finally and commit in the next day or two.

    I don't have a good programmatic fix for svn: vs https: yet. Not sure there will be one.

    Patch.
    SVNThrottle.patch

  9. #59
    Senior Member
    Join Date
    Oct 2013
    Posts
    233

    Default

    Thanks for sticking with this.

  10. #60
    Developer fronobulax's Avatar
    Join Date
    Feb 2009
    Location
    Central Virginia, USA
    Posts
    4,198

    Default

    r18678

    I moved the update all to a thread pool and made the pool size a preference (svnThreadPoolSize). The default value of 2 actually seems to run faster on my system than the old way. That's probably because update all is reusing threads rather than creating a whole bunch and then destroying them. I decided there was no reason to introduce additional delay, but if there is a reason to do so it is a simple change to the ExecutorService.

    The recommendation from SourceForge was to use svn: instead of https: as the connection protocol because it makes fewer connections. However there are comments in the SVN code that imply changing the protocol is not going to work, even with the switch command. So the only safe way, AFAIK, to change protocol is to delete the local copy and then grab a new copy using the svn: protocol.

    So I think we need to gradually migrate published URLs to use the svn protocol but the user will have to decide to delete and update. At some point in the future support for automation can be considered but it might not be needed.

    Needless to say, if SourceForge is complaining about too many connections or something similar that is probably worthy of further investigation. I think one error updating a script will not stop the update all from trying the others, but I may be wrong and need to reconsider implementation.

    But as poorly trained customer service reps who don't want to deal with your problem say "It is working for me" :-)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •