Feature - Implemented svn() command for ASH

[Bale]

boolean svn(string project) - Does mafia have a working copy for project?
boolean svn(string project, boolean uptodate) - Is mafia's working copy for project up to date?


It would be helpful if there was an ash command that could check the svn to see if a certain script is up to date.

For instance, WHAM might want to check svn("BatBrain", true) and svn("SmartStasis", true) and if there is a new revision, the function would return false so WHAM could automatically cli_execute("svn update"). Or more likely, a script might want to check its own revision and update if necessary.

 

[lostcalpolydude]

How is mafia supposed to know if a script is up-to-date? Just because you used "svn update" 10 seconds ago doesn't mean the script author didn't commit a change in that time. There could maybe be a boolean to track whether "svn update" was used today already.

 

[Bale]

Actually, I was assuming that the svn() command would check the svn repository when it is used. I was also assuming that the script writer would be responsible just as with current script updating methods of checking the forum, the information would be stored in /data or a _preference so that it doesn't need to be checked again that day.

With the recent update for _temp preferences, it would be really obvious to silently set_property("_checked"+project, "true") and rest assured that after login the preference would be deleted.

 

[lostcalpolydude]

I was also assuming that the script writer would be responsible just as with current script updating methods of checking the forum, the information would be stored in /data or a _preference so that it doesn't need to be checked again that day.

I had no plan to do that, since I expect people to regularly run "svn update", especially with there being an option to do it on login. If mafia is checking sourceforge (or wherever) anyway, why not do an actual update if one is needed, rather than reporting back that an actual update is needed?

 

[fronobulax]

I think Bale's point is about dependencies. If my script depends upon a particular version of someone else's script then I can pre-empt an unpleasant user experience by detecting that there is an update for the dependencies and act accordingly.

In the current, non-SVN, state a dependency can be changed, manually downloaded and then be discovered to have broken something that depends upon it. The solution, when the goal is to burn turns and not debug code, is usually to revert the dependency and inform the author of the script that the new version breaks the script and wait for an update.

I can see the utility of the command now but given the discussion about auto-handling of dependencies as a future feature, I can also see defering it for now.

This does suggest, however, that as a user I would like a revert command that pretty much gets the previous version. This also suggests that I would not use an auto update on login feature until dependencies were handled in a rational fashion.

 

[roippi]

I have some concerns about the proposed functions. For the first, people are going to want an equivalent of "svn list" eventually, so why don't we just make that and let people do svnList.contains( "project" ).

For the second, does the boolean argument to the function actually do anything? Or is it just there to make its overloaded signature distinct?

As for the utility of the check-revision-is-HEAD function, I'm less concerned about that. If scripters want an API to interface with svn, might as well give them the tools even if they're not strictly necessary.

This does suggest, however, that as a user I would like a revert command that pretty much gets the previous version.

Checkout-HEAD-minus-1 doesn't really cut it, as the velocity of SVN updates can be much higher than the post-file-to-forums release schedule. The one that's working could be a number of revisions behind HEAD.

A "decrement" function if you want to have the ability to incrementally bump back your revision until it works could suffice. I wouldn't call this "revert" because that means something specific.

 

[fronobulax]

A "decrement" function if you want to have the ability to incrementally bump back your revision until it works could suffice. I wouldn't call this "revert" because that means something specific.

Decrement would work. I had brain flatulence when I said "revert" because I know that means throw away local changes and grav the latest version from the repository. What I meant is a variation on Update to revision (to steal Tortoise phrasing) where revision was whatever my local copy was before the most recent update. Given the difficulty of determining that automatically go back one revision would suffice.

 

[roippi]

It's pretty easy to bump a working copy up/down one revision. r12157 should let you do that.

(hurray filling feature requests that have nothing to do with the one in the OP? >.>)

 

[fronobulax]

It's pretty easy to bump a working copy up/down one revision. r12157 should let you do that.

(hurray filling feature requests that have nothing to do with the one in the OP? >.>)

I am pleased that you have taken the ball and run with it so I don't really care where you post what - except it is nice to keep the documentation separate.

 

[slyz]

I haven't had much time for KoL and Mafia lately, but I try to keep up with all the recent SVN features.

How is mafia supposed to know if a script is up-to-date?

I guess script authors are going to start using SVN exclusively since it makes the process of updating the script easier for everyone. With one click, the change to the script is committed, and soon every user will "svn update" when starting Mafia. That means the method of posting the script to a forum post will be slowly deprecated.

I think we are missing something akin to Mafia's point releases in this process: everyone will be beta-testing recent changes to scripts, unless they turn off the automatic svn update and follow the script thread to know when it's safe to update, which kind of defeats the point.

I don't think SVN has this feature, but it would be great if Mafia knew that a script is "up-to-date" (ie whether you have the latest stable release).

EDIT: what made me think about this is the way BCC and Winterbay work on bumcheekcend. Winterbay commits tons of stuff to sourceforge. Some users grab the "daily" script and report issues. Once these are fixed, BCC spins a "point release" that triggers an update message (I think).

EDIT2: Gah, the solution to this is really simple. Script authors can simply have two versions of their script: "bumcheekcend_stable.ash" and "bumcheekcend_beta.ash". Changes are committed to the beta version, until BCC is feels it is ready for a point release. He then copies "bumcheekcend_beta.ash" to "bumcheekcend_stable.ash" and voilà.

 

[lostcalpolydude]

I think we are missing something akin to Mafia's point releases in this process

I don't know how useful that is in mafia any more, other than the fact that it provides a reminder for some people to update.

EDIT: what made me think about this is the way BCC and Winterbay work on bumcheekcend. Winterbay commits tons of stuff to sourceforge. Some users grab the "daily" script and report issues. Once these are fixed, BCC spins a "point release" that triggers an update message (I think).

Script writers can adapt to the idea that more people will generally have the latest version of the script, or they can keep using forum updates as they do now. Script users can update individual scripts instead of all of them if they have scripts that regularly have issues when they are updated.

Your second edit idea would work, but I think it will be less common due to the extra effort for both script users and script writers.

 

[Winterbay]

I currently have a WHAM and a WHAM_dev on my drive for this reason (well mainly because my /scripts folder is shared with a friend who does not always want my bleeding edge changes and so it's easier that way). I would have no trouble having two versions ofthe script in the SVN.

 

[roippi]

svn has features for all of this if people want to use them. It is a version control system, after all.

You can have any number of development branches where you are testing features - maybe individually - and when they're ready to go you can do svn merge to merge it into trunk. It takes some time to learn the feature up front, but basically zero time once you get the hang of it.

 

[slyz]

Your second edit idea would work, but I think it will be less common due to the extra effort for both script users and script writers.

You're right, not many scripts would need this kind of arrangement.

I think it would benefit mostly scripts with multiple authors, since multiple authors generally means that the script is dealing with something complex where having a stable and a beta version makes sense.

WHAM depends heavily on BatBrain, so it can fit in the "deals with something complex" category .

EDIT:

svn has features for all of this if people want to use them. It is a version control system, after all.

Oh good. That shows how much I know about SVN. I still have something called svn-book.pdf in my mafia dev folder, created 2010-09-16, soon after I was granted commit access. I never read past the intro, I think.

Are common users who want to beta-test able to grab development branches too?

 

[roippi]

Oh good. That shows how much I know about SVN. I still have something called svn-book.pdf in my mafia dev folder, created 2010-09-16, soon after I was granted commit access. I never read past the intro, I think.

Are common users who want to beta-test able to grab development branches too?

It's up to the person who's in control of the repo, but I would hope so. We're all open-sourcey here and whatnot.

People who want to learn more about svn's branch/merge system can read here. It's actually a well-written thing with most of its explanations in lay English. TortoiseSVN lets you do most of the discussed CLI commands in a graphical environment, so if you're using that you can focus on the concepts without worrying about the syntax.

I could write Yet Another Guide but I think honestly the above link does a better job than I'd do.

(I'll get to the ASH commands eventually, sorry, keep getting sidetracked in this thread)

 

[roippi]

r12198

boolean svn_exists( String projectname )
boolean svn_at_head( String projectname )