Not a bug - not a script problem - sourceforge issues

[heeheehee]

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.

Does SVNKit support `svn relocate`?

svn info | grep -P '^URL:' | perl -pe 's/^.*?https/svn/' | xargs svn relocate

seemed to work for me in ~/.kolmafia/svn/mafiarecovery/ as a proof-of-concept.

 

[xKiv]

Yep, relocate is what you should be using.
Switch is for moving the root path within a larger repository.
Relocate is for changing the URL for the entire repository.

 

[fractalnavel]

svnThreadPoolSize=5 worked for me. 1 is slow.

Did svn update used to update scripts that were moved into folders under the scripts folder? I try to add a little bit of organization since there are so many.

 

[fronobulax]

Yep, relocate is what you should be using.
Switch is for moving the root path within a larger repository.
Relocate is for changing the URL for the entire repository.

Whatever you say

SVN supports a switch/relocate command, which just changes the URL that needs to be changed for that. Worst case, you can do it from command line (you might need to get command line tools that support the same version of local repository as mafia's copy of svnkit does; I think svnkit has commandline tools that can do that).

 

[xKiv]

Whatever you say

Well, I am learning this too, myself.
(apparently, you can spell svn relocate as svn switch --relocate ? or maybe it's just that the second command can do both things at once?)

I never had any reason to use switch and the last time I used relocate was many years ago. The new hotness for my employer has been git for the past few years. That has very different complications.

 

[fronobulax]

svnThreadPoolSize=5 worked for me. 1 is slow.

Did svn update used to update scripts that were moved into folders under the scripts folder? I try to add a little bit of organization since there are so many.

Two was faster on my old system than the old version based upon one precise timing with a sweep second hand on an analog watch I only update 30 or so scripts which certainly has an impact on the results.

It is user configurable for a reason and the best answer for any system is the highest number that does not trigger Sourceforge to reject connections.

Update All traverses the svn subdirectory in the mafia directory tree and updates everything there. AFAIK I did not change the behavior where mafia fetches an update and then pushes it to scripts or elsewhere. What would be most helpful would be to a) confirm that something is broken; b) write a detailed bug report so that I can reproduce it locally; and c) make sure I know about it. If I really broke something I accept responsibility for fixing it.

 

[fronobulax]

Well, I am learning this too, myself.
(apparently, you can spell svn relocate as svn switch --relocate ? or maybe it's just that the second command can do both things at once?)

I never had any reason to use switch and the last time I used relocate was many years ago. The new hotness for my employer has been git for the past few years. That has very different complications.

The comment above WCAtHead in SVNManager says

Users who have used svn switch on some of their project should not use this.

Since we are using that code, prudence dictates some investigation and experimentation. "First, do no harm." seems to apply.

I will confess that I am not too worried about changing https: to svn: on legacy scripts. The thread pool provides an absolute upper bound on the number of simultaneous Sourceforge connections. The exact number does depend upon protocol but the existence of a user configurable bound does not.

 

[heeheehee]

Well, I am learning this too, myself.
(apparently, you can spell svn relocate as svn switch --relocate ? or maybe it's just that the second command can do both things at once?)

I never had any reason to use switch and the last time I used relocate was many years ago. The new hotness for my employer has been git for the past few years. That has very different complications.

It looks like svn switch --relocate was how you did this in old versions of SVN. I wouldn't know, since I haven't really used svn (beyond one-off commands for tinkering) in... some time now.

 

[fronobulax]

It looks like svn switch --relocate was how you did this in old versions of SVN. I wouldn't know, since I haven't really used svn (beyond one-off commands for tinkering) in... some time now.

DEC's VAX/VMS had a lot of influence on how I like to do things. The file system had some automatic versioning and I got used to the idea that I could go down a rabbit hole with edits and easily get back to where I started. So at various times I maintained a local SVN repository of all my important stuff and a lot of Update, Revert and Commit. But I never moved repositories and when someone else did I just deleted my working copy and grabbed a new one. So the existence and implications of relocate are new to me

I think the repository URL is "embedded" in the local working copy and the KoLmafia always goes to the working copy to get update info. So I think it would be safe to replace all the https: with svn: for SouceForge links in our json file. AFAIK that will have no impact on people who have already installed and all new installations will use the friendly protocol.

There are ash commands that will display the URL so users with "legacy" URLs could follow my procedure and delete and check out or someone can see whether we exposed some kind of relocate command and how well it works

 

[xKiv]

I just
1) updated and built mafia from current svn
2) installed current tortoisesvn (1.10)
3) upgraded all my mafia/svn/ script directories (to workspace version 1.8)
4) relocated them all from https://... to svn://...
5) ran mafia and did "svn update" in it

All scripts checked revision and updated without any error. It was slow, but that might be because the thread pool is only 2.