My scripts: svn -> git

Veracity

Veracity

Developer
Staff member
I've migrated all my scripts from SVN on sourceforge to GIT on github.

Advantages of this:

- I can have a README.md - documentation - for each script.
- Instead of a "To Do" list inside the script, I can create Issues at github.
- You can still make suggestions on the threads here, but you can also open Issues to propose things. Be warned that I'm not used to that, so we'll see how often I respond, but the advantage is that unanswered suggestions will no longer disappear into previous pages of the forum thread.
- I'm open to user-authored pull requests - but you have to match my preferred code style, at least. :)

I will update the threads I have for each of them, but I figured I'd discuss this a bit here, since I will no longer be pushing updates to sourceforge, and I suggest you uninstall the SVN versions and install the GIT versions so that you can use "git update".

I did not transfer over the revision history because I sort of screwed up when I launched them on sourceforge: they were all under a single repository, so a change to any of them bumped the version number of all of them. That will no longer be the case; a change to VeracityMeatFarm will no longer "require" an update to the (unchanged) VeracitySpacegate script.

By and by, I will update the Script Registry to have the new repositories in place of the old ones.

If you have personal changes to any of my scripts, you'll be able to modify the script in the local git directory and updates from me should merge, just as they do for SVN, thanks to Ryo_Sangnoir's recent work.

So, I suggest the following:

For each script of mine you have installed:

1) (If you have local changes, stash the file somewhere)
2) From Script Manager, Delete the installed script -> make sure you have r27304 of KoLmafia first!
3) From the gCLI, Install the migrated script
4) (If you have local changes, merge them.)
5) (Save the merged files in your local git repository under the "git" directory.)

Scripts:

vprops.ash
Code: 
git checkout Veracity0/vprops

This is a dependency for almost all of my other scripts. Delete the SVN version of this script before updating any other script, since they will install the GIT version and if you try to delete it later, it will disappear from your "scripts" folder.

vcon.ash
Code: 
git checkout Veracity0/vcon

This is a dependency of VeracityMeatFarm. Delete the SVN version of this script before installing the GIT version of that script.

VeracityMeatFarm.ash
Code: 
git checkout Veracity0/meat-farm

I added some changes to this which you will have to merge: For all external scripts that it calls, it checks for either a SVN or GIT version to see if it is installed. That includes both my scripts and "combo". I call the same function to check Ezandora's scripts, although they have not yet announced git access. That should be easy to fix, since they are hosted on github.

Garden Harvester.ash
Code: 
git checkout Veracity0/garden

I have some local changes for the Rock Garden which are incomplete. That will be an upcoming (soon) update.

Gingerbread City.ash
Code: 
git checkout Veracity0/gingerbread

BeachComber.ash
Code: 
git checkout Veracity0/beach

Arrrbor Day.ash
Code: 
git checkout Veracity0/arrrbor-day

VeracitySpacegate.ash
Code: 
git checkout Veracity0/spacegate

Spacegate Sounds
Code: 
git checkout Veracity0/spacegate-sounds

This depends on Ezandora's Choice-Override relay script utility.
I have verified that you can install that using git.
I have not yet changed the dependencies.txt to do it that way.
I'll be looking at that soon.
 
I see this as an inevitable migration. Do you have any hints or lessons learned or merely the instructions you followed to assist when other people follow suit?
 
For dependencies on GitHub that may be installed using SVN (mostly Ezandora's scripts), it's preferred to use the custom "github" syntax (e.g. as in https://github.com/phulin/shorts-ui/blob/master/dependencies.txt):
Code: 
github Ezandora/Choice-Override Release
This will allow the user to have the script installed in either SVN or git, which can be useful if they use a different script which forces SVN install. If not installed, it will default to installing using git.

On linguist, if the language is ever added to GitHub it will have the name "KoLMafia ASH" (as in https://github.com/smola/language-dataset). It's likely not popular enough, though. Adding it with that language at the moment will, I think, just make linguist ignore all the files as it does currently.
 
I uninstalled all of your scripts, including vprops, from the Script Manager and then reinstalled using git. When I issued the following command in the gCLI:
call VeracityMeatFarm.ash
Click to expand...
I got a long list of errors that all seemed to lead to a missing "vprops". A "git list" command yielded the following:
Veracity0-arrrbor-day
Veracity0-beach
Veracity0-garden
Veracity0-gingerbread
Veracity0-meat-farm
Veracity0-spacegate
Veracity0-spacegate-sounds
Veracity0-vcon
Veracity0-vprops
Click to expand...
I tried "git update" and nothing was updated. I then tried "svn update" and vprops was installed as
veracity0-vprops
Click to expand...
After it was installed, via SVN, calling VeracityMeatFarm worked as expected.

I'm not sure what is going on.

Edit: Still not sure what is going on but I have two, installed via svn, scripts that import vprops:
  • digitrev-fishbot
  • kolm-prefs
Still digging
 
Last edited:
Whoah! I was wondering if anyone else used vprops. Apparently so.

When I was incrementally moving my scripts to github, the first was vprops. I verified that I could add and delete from GIT and delete and add from SVN, and scripts could successfully validate - even if the script dependencies still called for the svn repository. That is expected; validation only cares that the script is installed in your "scripts" directory.

Adding a new script will download files into your local repository under svn or git and then copy them to scripts/data/....
Deleting a script will remove installed files from scripts/data/... and also remove the local repository under svn or git.

The only way I can see that files would be missing from scripts/data/... is something like this:

Have svn repository and installed files
Add (same) git repository - which should overwrite existing files?
Delete svn repository - which deletes installed files.

git update would not copy files, since there is nothing new.
How about git sync?

In any case, since you have scripts which depend on vprops via svn, for now, you need both.
I will be updating the git version - We added the "path" primitive data type and vprops doesn't do that, yet.
I will not be pushing the svn versions, but scripts that have that as a dependencies will use whatever is installed.
 
What puzzles me is that the git version of vprops was, and is, installed and the git version of VMF wasn't finding it.
 
The script looks for vprops.ash in your scripts folder, not in your local repository.
If it is not there, the script cannot compile.

"git sync" should reinstall it in the scripts folder.
 
Ryo_Sangnoir said:
For dependencies on GitHub that may be installed using SVN (mostly Ezandora's scripts), it's preferred to use the custom "github" syntax (e.g. as in https://github.com/phulin/shorts-ui/blob/master/dependencies.txt):
Code: 
github Ezandora/Choice-Override Release
This will allow the user to have the script installed in either SVN or git, which can be useful if they use a different script which forces SVN install. If not installed, it will default to installing using git.
Click to expand...

This is what I need.

As it turns out, I have four Ezandora choice relay scripts - Source Terminal, Bastille, Genie, and Mummery - whose dependencies.txt files have the SVN version - as well as my own spacegate-sounds.

Is Ezandora still around?

Ryo_Sangnoir said:
On linguist, if the language is ever added to GitHub it will have the name "KoLMafia ASH" (as in https://github.com/smola/language-dataset). It's likely not popular enough, though. Adding it with that language at the moment will, I think, just make linguist ignore all the files as it does currently.
Click to expand...
How can I "add it with that language"? I was unable to find a place to configure that.

I was not happy with my repositories being labeled as "AQS Scripts", so I added the .gitattributes file to tell linguist to ignore .ash files.

Supposedly, linguist wants 200+ repositories to use a new language before they will consider adding it.
I am pleased to have added an additional 9. :)
 
Veracity said:
Is Ezandora still around?
Click to expand...
Ezandora isn't active. Fortunately, most of her scripts are installable with git, but some aren't. I've created forks and filed PRs for the ones I use, and the only thing you can really do until the PRs are accepted (which I don't expect to happen any time soon ;) ) is switch to using the fork instead.
Veracity said:
How can I "add it with that language"? I was unable to find a place to configure that.
Click to expand...

You've set linguist-detectable=false. If the language were accepted, you could set linguist-language=KoLMafia ASH. As it is, I think that's the same as telling linguist to ignore the files.
 
Ryo_Sangnoir said:
I've created forks and filed PRs for the ones I use, and the only thing you can really do until the PRs are accepted (which I don't expect to happen any time soon ;) ) is switch to using the fork instead.
Click to expand...
Ha. I see your PR in Bastille.
I also have an improvement for that script. I should file a PR of my own, to sit there and languish like yours.

What is it that makes a particular script installable via either svn or git vs. only via svn?
I just browsed Ezandora'a repositories and I see scripts I didn't even know existed.
For example, her Latte relay script. Installable via
Code: 
svn checkout https://github.com/Ezandora/Latte/trunk/Release/
There is not, however, a git branch for Release.
 
If a script is installable only from a subfolder (i.e. the "scripts" or "relay" folder is not in the root of any branch), it needs a "manifest.json" file to tell the git install where the "root" folder is.

SVN can checkout a repository starting from a subfolder, but git can't.

Some of Ezandora's scripts have a separate release branch, and those are installable. Some just have a subfolder under the main branch, and those aren't.
 
So, basically, if Ezandora/Latte had:

manifest.json
Code: 
{"root_directory":"Release"}

(and also a fix to dependencies.txt for Choice-Override)

We could simply do
Code: 
git checkout Ezandora/Latte

I can envision another series of PRs to be ignored.

Although that might be simpler for her than setting up a Release branch and shuffling folders around, assuming we could talk her into updating her otherwise abandoned scripts to be git installable, rather than simply dying when github removes SVN support.
 
Indeed, I've filed PRs for the scripts that I use. So either she accepts the PRs and we can continue using her scripts straight, or she doesn't and I end up installing from the fork instead
Code: 
git checkout midgleyc/Voting-Booth
 
Maybe mafia could make some assumptions when satisfying dependencies with existing git installs given the svn id vs the git id. Like for all the Ezandora scripts I have installed via git where a dupe got installed via svn the only differences is the additional "-branches" text in the id:

Code: 
> git list

Ezandora-Bastille-Release
Ezandora-Briefcase-Release
Ezandora-Choice-Override-Release
Ezandora-Detective-Solver-Release
Ezandora-Far-Future-Release
Ezandora-Gain-Release

> svn list

Ezandora-Bastille-branches-Release
Ezandora-Briefcase-branches-Release
Ezandora-Choice-Override-branches-Release
Ezandora-Detective-Solver-branches-Release
Ezandora-Far-Future-branches-Release
Ezandora-Gain-branches-Release
 
We can guess, but we can't be sure.

For example, in git, "Ezandora-Bastille-Release" could be:
  • user Ezandora, repo Bastille, branch Release
  • user Ezandora-Bastille, repo Release
  • user Ezandora, repo Bastille-Release
This is something I'd really prefer to just put onto the user.
 
You must log in or register to reply here.
Back
Top