SVN Discussion

Z

zeryl

New member
Continued from http://kolmafia.us/showthread.php?1...w-your-old-diet-stacks-up).&p=34850#post34850

I agree, the knowledge level required for SVN is in fact a little higher.

For a long time, (please don't kill me for this) WoWAce used SVN almost exclusively for keeping addon's up to date. They have since moved away from that due to them be acquired by another company, but it seemed to work fairly well there.

I would also think it'd be quite easy to build a "revision" page based on the SVN contents, and keep that up-to-date (as a commit is done). Using $Id in the script would even be able to make sure there were no typos with the script version.

Just my $.02 from a development/maintenance standpoint (plus being able to two-click update scripts would be nice!)
 
I haven't managed a SVN repository in a while but I believe the following would be feasible.

New users can be directed to a URL to get the latest version of a script. The web repository browser is there "out of the box".

At least two possible ways to manage updates and notification.

Option 1 - A script is registered with mafia either by user action or automagically. At start up mafia checks for newer versions of every registered script and offers the user the opportunity to download them or not. This happens every start up so (until the complaints get too loud) user will be nagged every start up if they choose not to update.

Option 2 - Create an ash command that will check the current version against SVN and give the user the opportunity to manually update.

The latter is very close to what people who use zLib have now except that it would be looking at a SVN repository and not scraping a page at kolmafia.us for version information.

If the repository is organized so that each script has its own subdirectory, is it possible to assign commit access at the level of that subdirectory? If so then a SVN Admin just creates the initial directory for a new script and assigns commit privs to the initial writer. Script owner can then either be the proxy for updates or request that others be granted commit priv.

I like Option 1 but am not sure how to do it without implementing a portion of a SVN client in mafia and I wonder whether doing so in mafia is a significant change in direction or philosophy? Option 2 could probably be done using nothing but ASH although web scraping will look ugly.

I am not sure how to handle scripts that have been locally modified. Some scripts do ask people to edit variables and preferences. zLib can be used to avoid the problem but that requires the script writer to take advantage of that. Of course, if checking versions against a SVN repository becomes embedded in zLib then the writer already has zLib and just has to use more features.

Incomplete but close...
 
Between the two choices above, I'd suggest 2...

the problem with this path ultimately is that either we go down the path of "These are the scripts everyone uses, we update them automatically, but no... they're not official..." (number 1), as well as "Using client I haven't updated in 4 months and the scripts don't work right. What's wrong?" that so often crops up with the random posts now (both 1 and 2, SO much worse with 1 since you get the scripts complaining at you regardless of whether or not your client can actually support the most recent version of the script). Another issue I see with both is that ultimately, it's still very similar to the current system and its problems... someone disappears and hasn't given editing rights to their script, and it's still stuck.

As long as the execution is fully voluntary, and the end-user experience is as good or better than the current one, I'd say consideration is a good thing. What we don't want to do is shunt users off in every direction until they avoid KoLmafia because of how much of a pain it is to figure out what the most recent wandering is...

I suppose (at this point of barely awareness) what I'm trying to say is something like, how much will the SVN system confuse "standard" users that already often ignore updates for months and then ask about why it doesn't work instead of updating? Are they going to end up wandering the folders of the SVN and ultimately either give up, or download the wrong file?

And do we care?
 
I don't recall how fine grained granting commit privileges can be but since there will have to be a SVN Administrator, that person should be available to step in and give someone (else) commit access in the case of abandonware so SVN could be an improvement.

I'd like to believe that users who are sophisticated enough to use scripts understand about updating mafia also, but to the extent that is not true, it is a strong argument in favor of something like Option 2.

Using zeryl's mock up as an example, the latest version of zLib would always be available at http://zeryl.mine.nu/svncon/dl.php?repname=KOL+Mafia+Scripts&path=/zLib/trunk/zlib.ash&rev=7&peg=7& I suppose it would be nice to have a "friendlier" URL but I would have no problem hardwiring that in a tool that always grabbed the latest version or hiding it in a "Click here to get the latest version of zLib" kind of post. (Actually, as I look at it that 7 is suspicious so maybe the URL would change. However SourceForge has clearly solved the fixed pointer to the latest version problem so we could too).

So if I am thinking things clearly, moving to SVN is no worse than the current situation (once the ASH version checking in zLib is rewritten to use SVN) and has some slight benefits for users.

The benefits for script writers who are willing to install and/or use a SVN client are huge. IMO.

What I don't know is how to associate a revision number with a particular download and determine whether an update is available but SVN clients can do that so I'm not too worried. Worst case is there will have to be some new ASH functions.
 
Theraze said:
I suppose (at this point of barely awareness) what I'm trying to say is something like, how much will the SVN system confuse "standard" users that already often ignore updates for months and then ask about why it doesn't work instead of updating? Are they going to end up wandering the folders of the SVN and ultimately either give up, or download the wrong file?
Click to expand...

Most users understand a forum system where the first post has the relevant file. It looks familiar and is a useful standard. Something new and different will always put people off -- the crucial part is balancing the positive against that. As I understand it, the problem is when scripts are abandoned and essentially "move" location/author.

The way subversion can mitigate this is to allow multiple authors to work maintaining the same code. Is that about the gist? A central subversion repository would be a useful way to keep the code maintained, and wouldn't necessarily lead to a complete redirection for users.

The above two paragraphs are really just me confirming I understand the issue. If I've got something wrong, please let me know! (And feel free to ignore the following comments)

On to relevant stuff:

I much prefer Option 2. Firstly, as Theraze said, checking through mafia muddies the separation between mafia and ASH. Mafia facilitates scripting, but it doesn't officially support any individual scripts, as far as I'm aware. If users see mafia (not the script) checking things, then it becomes confusing.

Secondly, a zlib-like function can get the revision from the repository, and direct people to the relevant location. At the same time, a forum post can link to the repository, meaning for a lot of users' behaviour is much the same as before (albeit two clicks instead of one). This has the double benefit of keeping script behaviour to the scripts, and keeping things much the same for users, but better for script writers.

So, in direct answer to Theraze's question, the fact that there will only ever be one available script to download (the most recent one) is good for end-users. Simple, flexible updating for authors who want to use it is useful (and may even encourage joint projects). So, we do care, and it will probably be good for most people (since it can also be opted out of).

The biggest question is who would host the repository and can we guarantee consistent up-time?
 
Grotfang said:
Most users understand a forum system where the first post has the relevant file.
Click to expand...
Curiously, KoLmafia.us is the only place I have ever encountered this convention, but the internet is a big place and we almost certainly frequent non-overlapping portions of it.

As a script developer I want the ability to undo or revert my changes, store my work away from my local computer, identify distinct versions and easily figure out why they are different and who was responsible. That is basically SVN or any modern version control system. My biggest problem with the "first post" convention is that even the owners of the script (and by that I mean me) often get sloppy and fail to update the first post. There have also been a couple cases where other people have contributed and done so by posting complete scripts and not just a patch or diff file. I believe if we organize a SVN repository and the associated web front end properly then we can include a link in the first post of a thread that will always point to the latest version which means the first post never has to be edited but people can always look there with confidence.

I'm now convinced that my Option 1 above is not the way to go, but I did need to throw it out there first. I also wanted to know whether it would work and make sense. If it does then we can see about hosting and reliability. I will note, for example, that free hosting at SourceForge might even be feasible.
 
To touch on a few points:

I don't recall how fine grained granting commit privileges can be but since there will have to be a SVN Administrator, that person should be available to step in and give someone (else) commit access in the case of abandonware so SVN could be an improvement.
Click to expand...

This can be controlled per repository (overall access) or even down to script level, if necessary. Ideally, it would not be open for commits by anyone and everyone, just to help prevent any accidents.

As for hosting, there are really two big options.

1) Use sourceforge for their hosting
2) Use googlecode for their hosting

Both should provide almost 100% uptime I'd assume. While this obviously is no guarantee, it's better than trying to host from a user's PC (the setup I show is just a prototype).

Additionally, using externals, you can specify a specific version of KoLMafia that is required, and have it load that as well. That is one larger benefit of this. It can help keep those folks updated who won't update manually. If they use an SVN client (what's better than one click updating everything), it can be downloaded with the script(s) they want to use.

As far as versioning and pretty URL's, again, I believe this is completely possible. There are significant bindings available for svn (Python, Java, etc), so it should not be a problem to write something for use in Mafia (if decided to add that support) to always grab the newest. (I think I just lost train of thought there, but don't want to erase it as it does have valid info).

Additionally, even if Mafia didn't do the full update internally, altering the method of version checking to look at an XML output of the current versions (which could be built out of the repo automatically), would be cleaner/easier than checking a forum post.

Ok, enough rambling for me.


Edit: Ok, so playing around a bit, just found this: http://zeryl.mine.nu/svncon/dl.php?repname=KOL+Mafia+Scripts&path=/eatdrink/trunk/EatDrink.ash No longer has a revision number in the URL, so it looks like it DOES download the most recent revision, getting rid of the concern about the revision in the URL.
 
Last edited:
Yeah... as long as all the users have to do is click on a file just like now, no additional signup or anything, I think it shouldn't be too much of a problem. I'm not sure if there's a good way to do unique download tracking like we have here, but if script writers do notify bits, it should work out. It's just nice to get the look at roughly how popular a script is before you possibly pummel your character... if it's been available for 6 months, and has 11 total downloads, there's probably a reason. :D

The big question is how do we make this work so that everything is available, but locked to the user, unless that specific user (or the administrator, if the script is abandoned for over a month or whatever time without fixes posted in the thread that everyone is using) allows more rights? Not sure if Googlecode has this functionality and fairly certain that the way Sourceforge does it isn't like this either?

Also, the question of who would be the administrator comes up... I'd suggest the main devs or someone like that, as they're less likely to disappear without grave consequences to the client itself.
 
If someone kind find the software to use to setup something like this I'd be willing to configure it.
 
There seem to be a number of sites that offer SVN hosting for free although not all of them offer the fine grained access control I think I would like to see. As noted above fewyn is also willing to host so it comes down to where and administration.

My thinking right now is that I (or someone with more time and tolerance for fiddling with HTML parsing) should write an ASH script that duplicates the functionality of zLib's version but uses a Kolmafia source file on SourceForge as the surrogate for the script file. That will pretty much demonstrate that this is feasible and not just me smoking something.

Top level admin depends upon where things are hosted but SourceForge, for example, makes that somewhat painless so I wouldn't mind and could probably recruit a co-admin easily. If there is no fine grained access control anyone who can commit can commit anywhere which is not a problem if people exhibit the same level of responsibility and maturity that I observe on kolmafia.us when it comes to maintaining scripts. If there is fine grained access control then there is no problem and the admin will have to deal with abandonware - which shouldn't be a big deal.
 
I don't mind hosting this, and even walking someone through how to host it.

Do the admins have a box it can be hosted on? Perhaps the server running the site?
 
If I understand correctly, fewyn runs kolmafia.us (and the kolmafia wiki). Since he offered to host this. Maybe you should shoot him a PM?
 
Throwing this out there -- I don't want previous versions of my scripts to be easily available (to save myself some support hassle), so if this is a possibility with SVN I wouldn't use it. The current "release" (which I'm very good about keeping in the first post, a convention which I have seen on several other forums in widely unrelated fields) will always be the best available version of the script, and if not I want to know why.
 
zarqon said:
Throwing this out there -- I don't want previous versions of my scripts to be easily available (to save myself some support hassle), so if this is a possibility with SVN I wouldn't use it. The current "release" (which I'm very good about keeping in the first post, a convention which I have seen on several other forums in widely unrelated fields) will always be the best available version of the script, and if not I want to know why.
Click to expand...

Just so you know yes previous versions are available but no their not easily available unless you know what you're doing. I'm just right now trying to think of the best way of going about setting up an SVN and giving people access to write to it. I obviously don't want *everyone* to write to it.
 
Just got bored, and installed visualsvn server on my vps, it looks like it does the job.

I think if done correctly, the managment console can be installed without the server allowing remote administration for administrators. i'll investigate some more if anyone wants me to, unless you have it covered fewyn?

-- edit: investigation complete, this is possible but only in the enterprise edition (nearly $1000)!

I'll be wiping the vps at some point in the future (it has plesk on it, which needs to be removed) and rebuilding, probably on a new ip, but the feed will be moved over and should remain the same.

Fewyn, if you want access to the vps give me a shout.
 
Last edited:
matt.chugg said:
I'll be wiping the vps at some point in the future (it has plesk on it, which needs to be removed) and rebuilding, probably on a new ip, but the feed will be moved over and should remain the same.
Click to expand...

Will that have any effect on your SVN Search utility? Just wanted to check, since I use it now and again.

Many thanks x
 
You must log in or register to reply here.
Back
Top