Mafia SVN for Scripts?

Project name is regex'ed out of the svn URL.
Ah phooey. Okay.
I don't think svn behaves like you think it does when you move local files, for one. But to answer your question, the same thing that's always happened. It uses the first one that it finds.

It's in my opinion a bug that we allow a name to be defined twice in the same namespace. I would prefer that we throw a runtime exception there.
How do you think I think svn behaves when I move files :p At this point my question was strictly mafia, no svn. I had always been under the impression that you had to explicitly state the location of an imported script, so I had never really thought about it.
 

Bale

Minion
The regex is posted here. It's actually the - in the first part that made it not match.

That's a bug then since it should allow any character other than a / like this:


Code:
	private static Pattern SOURCEFORGE_PATTERN = Pattern.compile( "/p/([^/]+)/code(.*)", Pattern.DOTALL );

Actually, that isn't sufficient for Winterbays needs either since that will give the same name to all scripts stored in a single sourceforge project. I'm sure that Winterbay and bumcheekcity aren't the only ones likely to do this.

I propose that if there is anything after "/code/" then that should be the project name, otherwise use the part before "/code". What should that more complicated regexp look like?
 

roippi

Developer
I propose that if there is anything after "/code/" then that should be the project name, otherwise use the part before "/code". What should that more complicated regexp look like?

Well, 1) you wouldn't need to do that all in regex, in java you can use matcher.group(1) and (2).

But 2) a given URL needs to uniquely map to a working copy folder. Stripping out the part before /code/ will result in project clash, especially because many people tend to do ../projectname/code/trunk/.

While were at it, any chance we could get some love for google code users?

Yes, I've said that we'll support other url formats. (and if you're hosting it yourself, you should probably just make the url match one of the existing regexes we support)

Note that giving me a regex is preferable to making me do the work and having your regex malformed anyway :)
 
Note that giving me a regex is preferable to making me do the work and having your regex malformed anyway :)
Code:
private static Pattern GOOGLECODE_PATTERN = Pattern.compile( "http://([^.]+)\.googlecode\.com/svn/trunk/([^/]*)", Pattern.DOTALL );
Ditto what Bale said: use group 1 if group 2 is empty. Otherwise use group 2 or possibly some conjunction of the two.
 
Last edited:

roippi

Developer
Also somehow didn't see/forgot to reply to this:

You could make it a tab in preferences for now since for me it is a higher priority than a GUI for the SVN. This is a prerequisite for me (and perhaps Winterbay) befire BatBrain, etc all start updating with svn.

Just so everyone's expectations are clear, I internally classify this as a Request For Enhancement - Cosmetic and prioritize it thusly. Cosmetic improvements take a back seat to bug fixes and feature requests dealing with the API.

I realize that some people love their scripts menu very dearly and seeing it sullied is a deal breaker. I am sorry that your inner OCD demons compel you so. I counsel you to remain patient and wait for the API to be fully implemented because I won't be looking at the scripts menu prior to that.
 

roippi

Developer
Code:
private static Pattern GOOGLECODE_PATTERN = Pattern.compile( "http://([^.]+)\.googlecode\.com/svn/trunk/([^/]*)", Pattern.DOTALL );
Ditto what Bale said: use group 1 if group 2 is empty. Otherwise use group 2 or possibly some conjunction of the two.

Is /trunk/ obligatory? Or just recommended, as with sourceforge?

Also, we can't just take the first subdirectory after trunk/, we have to take them all. Group 2 has to be (.*)
 
Is /trunk/ obligatory? Or just recommended, as with sourceforge?

Also, we can't just take the first subdirectory after trunk/, we have to take them all. Group 2 has to be (.*)

I have no idea if it's mandatory, actually. I'd assume not, but I'll have to check.

And ah, so it does. Not sure what I was thinking.
 

Bale

Minion
Just so everyone's expectations are clear, I internally classify this as a Request For Enhancement - Cosmetic and prioritize it thusly. Cosmetic improvements take a back seat to bug fixes and feature requests dealing with the API.

I realize that some people love their scripts menu very dearly and seeing it sullied is a deal breaker. I am sorry that your inner OCD demons compel you so. I counsel you to remain patient and wait for the API to be fully implemented because I won't be looking at the scripts menu prior to that.

Not a deal breaker. I'm not surprised at your answer either. Do you thing and enjoy it your own way. I'll survive, thrive and love this new svn yumminess.

Honestly I never thought I'd really like svn updating, but for a script like ChIT it gives me tremendous freedom to be able to change its many files and add images without worry that people will complain about the difficulty of updating. I even moved the image directory just because I never liked having two nested subdirectories when one would do the job. I feel little incentive to use svn for all my scripts, but it works so terribly well for ChIT that I don't know how I lived without it.
 

lostcalpolydude

Developer
Staff member
I feel little incentive to use svn for all my scripts, but it works so terribly well for ChIT that I don't know how I lived without it.

As a script user, any script that will need regular updates is easier to update with svn than by loading a forum thread and downloading the script every time. Another benefit is that scripts can have settings that are meant to be changed by the user at the top of the script, and changes will persist through updates, without having to use zlib variables or similar.
 

Bale

Minion
Yeah. I'm learning that. I'm going to have to eventually switch over all my scripts to svn updating. That also means I'll abandon zarqon's map manager because I can simply put my data files in the svn to save an extra step.
 

meowtiger

New member
Still a no go with proxies i'm afraid -

Is there any logging i can do to see where its hitting and where its not ?

Code:
> version
KoLmafia v16.0 r12158

> svn checkout https://svn.code.sf.net/p/mafiachit/code/
Unable to connect with repository at /p/mafiachit/code
 

livercat

Member
Huh, that's kinda weird. 12158 was able to "svn update" through proxy, but reported errors nevertheless:
Updating /p/mafiachit/code
Validating repo...
Something went wrong while fetching svn directory info
D:\Dropbox\kolmafia\svn\mafiachit
AU https://svn.code.sf.net/p/mafiachit/code/images/chit/effects.png
AU https://svn.code.sf.net/p/mafiachit/code/images/chit/tracker.png
https://svn.code.sf.net/p/mafiachit/code/images/chit
https://svn.code.sf.net/p/mafiachit/code/images
U https://svn.code.sf.net/p/mafiachit/code/data/chit_effects.txt
https://svn.code.sf.net/p/mafiachit/code/data
U https://svn.code.sf.net/p/mafiachit/code/relay/chit.js
U https://svn.code.sf.net/p/mafiachit/code/relay/charpane.ash
U https://svn.code.sf.net/p/mafiachit/code/relay/chit.css
https://svn.code.sf.net/p/mafiachit/code/relay
https://svn.code.sf.net/p/mafiachit/code
At revision 16
Something went wrong fetching SVN info
Something went wrong fetching SVN info
Something went wrong fetching SVN info
Pushing local updates...
chit.css => D:\Dropbox\kolmafia\relay\chit.css
charpane.ash => D:\Dropbox\kolmafia\relay\charpane.ash
chit.js => D:\Dropbox\kolmafia\relay\chit.js
chit_effects.txt => D:\Dropbox\kolmafia\data\chit_effects.txt
tracker.png => D:\Dropbox\kolmafia\images\chit\tracker.png
effects.png => D:\Dropbox\kolmafia\images\chit\effects.png
Done.

My proxy settings just in case:
http
host: 172.16.34.70
port: 3128
all other fields are empty
 

fronobulax

Developer
Staff member
Are you under that impression? Because no.

Sorry for being unclear. To clarify, there was once a time when the file chooser would not traverse directories. That was done deliberately and as a security measure. A side effect of that decision was that you could not run a script (with a main) from the file chooser if the script was in a subdirectory. Maybe the file chooser has been opened up since then and I slept through it.
 

roippi

Developer
My proxy settings just in case:
http
host: 172.16.34.70
port: 3128
all other fields are empty

Well there's one problem, the code I wrote did nothing if it didn't find a user/pass.

try r12160. It may throw an NPE for you, I'm not sure if I'm allowed to put null user/pass strings into the authentication manager. If it does, post the debug log and we'll be closer than we were at least.
 

livercat

Member
12161: no debug log, but "svn update" stopped working.
Updating /p/mafiachit/code
Validating repo...
svn: E175002: connection refused by the server
Something went wrong while fetching svn directory info
D:\Dropbox\kolmafia\svn\mafiachit
At revision 16
Done.
Updating /p/towerchecker/code
Validating repo...
svn: E175002: connection refused by the server
Something went wrong while fetching svn directory info
D:\Dropbox\kolmafia\svn\towerchecker
At revision 2
Done.
 

roippi

Developer
12161: no debug log, but "svn update" stopped working.

It didn't stop working, it was just at the latest revision. That's how svn update works.

Looking into it more, the errors are coming out of some of my code for repo validation, which is just punting and allowing the update through. Which is fine, I guess.

I'll have to do more research on why my validation code works in non-proxy environments but not with proxies. For now, ignore the errors.

edit: r12163 might be a step in the right direction?
 
Last edited:

Winterbay

Active member
Just so everyone's expectations are clear, I internally classify this as a Request For Enhancement - Cosmetic and prioritize it thusly. Cosmetic improvements take a back seat to bug fixes and feature requests dealing with the API.

That's fine with me, I can live with having a strange menu as long as know that in the future I can make it less strange :)
 

livercat

Member
It didn't stop working, it was just at the latest revision. That's how svn update works.

Right, I was confused by the errors "E175002: connection refused by the server."

12163 seems to hit a spot, both with and without a proxy (log is identical in both cases):
Updating /p/mafiachit/code
Validating repo...
Repo validated.
d:\Dropbox\kolmafia\svn\mafiachit
At revision 16
Done.
 
Top