SVN and Changelog support (moved from BatBrain thread)

[xKiv]

I also don't want anything that stops automation, like an alert box or somesuch.

Doesn't that already happen when the update contains new files?

I think that would require the script to set a property indicating its current version for comparison.

SVN knows which revision number is currently checked out. Is that not sufficient?

 

[zarqon]

It's not sufficient to allow scripts to detect they were updated since their last run, which is what we were discussing. SVN knows, but the script doesn't. Presently I don't think scripts have access to any of mafia's SVN information about themselves other than a boolean showing whether they're current, which could be true on any number of runs following an update. An additional indicator would be needed, such as the revision number itself. We could manually enter this into the script each time we update -- as authors using check_version() are quite familiar with -- OR, since mafia's SVN knows this already, a better alternative would be an ASH function returning the revision number, which in addition to allowing update detection, would also give script authors one less thing to worry about. No more matching up version numbers in your script and your thread (now repository)! It's all automatic! woohoo

 

[roippi]

Doesn't that already happen when the update contains new files?

Yes, though most projects will stick to one file and will never see that popup. That alert is a security feature against malicious file injection and is basically the bare minimum level of security that I'd accept. Most users will click through it mindlessly, but at least they have a chance to stop it if something bad is happening.

a better alternative would be an ASH function returning the revision number

I'm not 100% sure how you'd use that differently than the current function, but yes, without hitting the repo server SVN is aware of metadata like

- revision number
- last local update time
- revision created time (i.e. when the revision on the server was created)
- author

and maybe some other stuff. I can trivially expose any/all of these that would be useful.

 

[lostcalpolydude]

I'm not 100% sure how you'd use that differently than the current function

The idea is that most of the update messages will get buried in all the stuff that happens when logging in and won't be seen. zarqon is hoping for a way to provide additional output when the script is run, if it has been updated since the last time it was run. The only idea I could think of was saving the current revision number to a setting (which would require a way to access it), and checking that setting each time the script is run to see if the revision number has changed (in the opposite order, I expect).

 

[Theraze]

I'm not 100% sure how you'd use that differently than the current function, but yes, without hitting the repo server SVN is aware of metadata like

- revision number
- last local update time
- revision created time (i.e. when the revision on the server was created)
- author

and maybe some other stuff. I can trivially expose any/all of these that would be useful.

Any chance we can do that using proxy values? Maybe $svn[script name] and then any information can be used by people without needing a large quantity of additional functions...

Edit: Thanks for the cleanup, minions.

 

[roippi]

Any chance we can do that using proxy values? Maybe $svn[script name] and then any information can be used by people without needing a large quantity of additional functions...

Edit: Thanks for the cleanup, minions.

Could technically do that. Making a new data type for this one informational function seems like overkill, though.

We could optionally pack it into a record, like the one version of maximize() and item_drops_array(). That syntax is a little messy though, since you have to iterate over it to save it to your own record.

 

[heeheehee]

We could optionally pack it into a record, like the one version of maximize() and item_drops_array(). That syntax is a little messy though, since you have to iterate over it to save it to your own record.

Would you necessarily need to save it to your own record, though? I'm imagining that most authors would just do something like

int revision = svn_metadata("zlib").revision;
if (revision < REQUIRED_TARGET) {
    abort("Your version of zlib is too old!");
}

 

[roippi]

Most users will only care about one field, yeah.

> ash svn_info("project1");

Returned: record {string url; int revision; string lastChangedAuthor; int lastChangedRev; string lastChangedDate}
url => https://svn.code.sf.net/p/mafiasvntest/code/myvalidproject1
revision => 16
lastChangedAuthor => roippi
lastChangedRev => 11
lastChangedDate => 2013-06-02 22:42:13 EDT (Sun, 02 Jun 2013)

 

[zarqon]

Eeeeexcellent. Transitioning begins now. Thank you all for putting up with my stink-raising, and in particular roippi for implementing it all.

Thanks also to whichever minion excised this from the BatBrain thread.

It took me two days to sign up for Sourceforge since I never received my confirmation email, and thus my account was "not enabled". Further, there is NO WAY on the site to automatically get it resent. I had to email support and wait for their response, which was of course to resend the email. Not very impressed, though I'm expecting the experience to improve drastically as I start migrating scripts there.

We'll do ZLib first, with a brand new check_version() that keeps existing functionality for now, while adding auto update for svn scripts and printing a changelog link if you have updated. Woohoo!

 

[Bale]

We probably could have settled this a while earlier if you'd started a conversation about your concerns instead of just sitting back and waiting to see what it would look like. You were too easy going.

Thanks also to whichever minion excised this from the BatBrain thread.

You are welcome.

It took me two days to sign up for Sourceforge since I never received my confirmation email, and thus my account was "not enabled". Further, there is NO WAY on the site to automatically get it resent. I had to email support and wait for their response, which was of course to resend the email. Not very impressed, though I'm expecting the experience to improve drastically as I start migrating scripts there.

Welcome to sourceforge. I'm only using it myself because google code seemed worse. I'd like to mention something poorly documented that I found. While you can create a separate project for each of your scripts, it is also possible to create a single project and then add your scripts as subprojects using Admin -> Tools -> Click to install: Subproject

Example of what a project with subprojects looks like: https://sourceforge.net/projects/bale/. I've got my OCD, AdventureAdvisor, New Life and a bunch of relay scripts all on the same project page. It makes organization a little saner for me.

 

[roippi]

Eeeeexcellent. Transitioning begins now. Thank you all for putting up with my stink-raising, and in particular roippi for implementing it all.

Yup. Like I've said elsewhere, I intend to provide the API even if/when I don't see an immediate use-case for it. We have a fully featured svn client built in to mafia, might as well use it.

When possible, I try to mirror the output of the actual svn command line client - for example, info. Sometimes mafia's version is going to be different from vanilla svn as a side-effect of our working copy/local copy implementation; see "delete" as a command that's rather different in vanilla.

In terms of future API... if there's any other commands that deal with working copies, I'd be fine with adding those. Or something like "svn log" that displays the last n commit messages. I don't really feel motivated to add "svn commit" or any repo-management commands, though they're possible. I think scripters should probably just be using an external svn tool to do those operations.

 

[zarqon]

You were too easy going.

It was more a combination of ignorance and trust. I had (and mostly still have) no idea about the nuts and bolts of SVN, and I strongly trust the mafia community to only make changes which improve mafia -- mafia's developers and all us people who give them feedback deserve a lot of credit for a history that has earned that trust several times over. In my ignorance I didn't feel qualified to offer any suggestions until I'd actually learned about it first, and I knew it was in good hands so didn't feel pressure to do so.

Also, thanks for the tip! Believe I'll be wanting to do that.

I don't really feel motivated to add "svn commit" or any repo-management commands, though they're possible. I think scripters should probably just be using an external svn tool to do those operations.

Wait, so mafia's SVN client only goes one way? News to me. While that's less convenient for authors than I'd assumed (personal aliases for updating specific scripts FTW), it's still brilliant. My favorite benefit of SVN for authors is that scripts can update before they're even called, which eliminates our old problem with scripts erroring out before they're able to notify users that they're out of date.

 

[roippi]

Wait, so mafia's SVN client only goes one way? News to me.

My issue with adding built-in commit support is that it is always going to be strictly worse than any external tool you would use. Like, a lot worse; I would never personally use it, and that means that I would develop it even more halfheartedly.

I really like how tortoiseSVN integrates into the shell, and I would absolutely recommend it to any windows user (seriously, use it). *nix users already have a command line client that, again, is strictly better than anything I'd be able to create. And a million other graphical alternatives. So yeah. It's not that I don't want to help out authors, it's that I think I'd be doing a disservice to authors by letting them use a vastly inferior tool.

 

[StDoodle]

I mostly lurk now, having pretty much retired from KoL itself, but I thought I'd chime in a couple things (then run and hide away again).

1) I agree w/ roippi about tortoiseSVN; I know nothing about SVN, not really a coder myself, but I used it a few times and found it fairly newbie-friendly. I also hear it "scales" well for those who want to become power-users, eventually, but can't speak to that.

2) Providing release notes as a data file seems like a nifty idea. Somebody should write a relay override that lets you view release notes, and it wouldn't be too onerous to come up with a standard format so that it could read all the notes it "finds." Tracking where to look for such things could be an issue I guess, but otherwise that seems like a good solution to me. Then, the cli output could just notify of changes, and the user could run said relay if and when they wanted further info.

 

[Theraze]

Would definitely be nice to be able to do svn commitnotes <release number> or something similar to read a specific commit message. Then that could be pulled in with a relay script or check_version or something to display the release notes. Someone could even potentially make a relay override that scans svn list to see your current scripts and then offers up the full series of release notes from current back to 1 for the selected svn project.

 

[roippi]

The function would be svn_log(String project). I'd probably just have it return every revision's log in an array of Strings where the index is the revision number (off by one, since there's no revision 0). Though I'd have to see how server-unfriendly that is for really mature/prolific projects, maybe it's better to provide the ability to specify a range. Shrug.

 

[Bale]

I really like how tortoiseSVN integrates into the shell, and I would absolutely recommend it to any windows user (seriously, use it). *nix users already have a command line client that, again, is strictly better than anything I'd be able to create. And a million other graphical alternatives. So yeah. It's not that I don't want to help out authors, it's that I think I'd be doing a disservice to authors by letting them use a vastly inferior tool.

How about a command that simply copies changes from my local copy to the /svn directory so that I can use tortoiseSVN to commit the /svn directory to the repository?
(I can use the /svn directory with tortoiseSVN without trouble, right?)

That would save a step in my workflow.

 

[heeheehee]

How about a command that simply copies changes from my local copy to the /svn directory so that I can use tortoiseSVN to commit the /svn directory to the repository?
(I can use the /svn directory with tortoiseSVN without trouble, right?)

That would save a step in my workflow.

I personally would prefer symlinks pointing to the files in the SVN folder. Of course, it wouldn't work under XP and would require admin privileges under newer versions of Windows, so...

 

[roippi]

How about a command that simply copies changes from my local copy to the /svn directory so that I can use tortoiseSVN to commit the /svn directory to the repository?

You could make changes directly to the working copy and do "svn sync" in order to get them over to the local copy. If you're doing something that requires doing that frequently I can see how that would get obnoxious, though.

My issue with making a sync that works in the opposite direction (cnys?) is that.. well, it's kind of a dumb operation. Dumb in the sense that the only reasonable way to implement it is to brute force search through every svn project, see if the local version of each file exists, then brute force copy every single local file over its working copy counterpart. It obviously would also never pick up new files that were added. And doing it automatically before update operations is in direct conflict with the syncAfterUpdate preference - the local copy would just get copied over the working copy every time. That's not an insurmountable issue, but it's certainly unintuitive.

So none of these issues are really reasons why it can't be done, just reasons why I'm not happy with any of the possible implementations.

(I can use the /svn directory with tortoiseSVN without trouble, right?)

Yes, folders in there are legitimate working copies just like you'd get from doing a tortoiseSVN right-click checkout.

I personally would prefer symlinks pointing to the files in the SVN folder. Of course, it wouldn't work under XP and would require admin privileges under newer versions of Windows, so...

That would be cool but yeah it's obviously not portable.

 

[heeheehee]

That would be cool but yeah it's obviously not portable.

I was going to suggest adding this feature for those of us running *nix OSes (and of Vista/7/8 users, those willing to modify one of their security settings and/or those crazy enough to run Mafia as an administrator), but that would be a bit silly

(well, okay, it'd probably just involve a try/catch, but then you'd lose some OS independence)