The goal of this tool is to expose the scripts of a binary stack in a fashion that allows them to be tracked via a version control system like GitHub. The repo linked above contains the output of the stack. Even though GitHub can't provide useful information about the changes in binary files, each time I perform a commit I include the corresponding binary stack. This allows easy download of the stack for use but also puts the scripts in a convenient place for review online.

Each script in the stack is exported as a valid .livecodescript file, but the stack is not modified to make it a behavior. A custom property set is created for each object to track a hash of the script and the modification date/time of the exported file. On each sync, those properties are used to determine if the script needs to be exported or if the file needs to be imported. Whenever a script changes, a diff file is created that contains all of the changes in that particular sync operation. If a file is no longer needed (i.e. the script was removed), then the extra files are moved to a separate directory and renamed to ensure no name collisions. I have a .gitignore file configured to skip those files when considering changes.

The stack features an automatic import feature which watches the script directory looking for files that change. If a file changes, then a sync is performed on that individual file (presumably importing some changes). There is a stack level preference to allow a choice of how to handle the situation when a change is detected in both the script and the file (script {keep stack script/overwrite file}, file {import file}, ask {present options in a dialog}, skip {keep stack script, but do not update the hash nor overwrite the file}).

If automatic import is enabled, there is also an option to have scripts opened in an external editor. When enabled, whenever the IDE wants to edit a script it will also get opened in the chosen external editor. If an object doesn't have a script yet, then a temporary comment is added to create a file for editing.

There is an option is to have a sync performed before saving the stack file. This is done with a front script that intercepts the SaveStackRequest message to initiate the sync if required.

The system is designed to be non-destructive, so the way to completely remove a file is to clear the script in the IDE and perform a sync. Deleting a file from the operating system and performing a sync will just regenerate the file. If you remove everything after the header, the file will get removed on the second sync (the first will import the blank script into the IDE, but not remove the file).

The stack currently handles a single mainstack at one time. There is a drop down menu with all non-IDE mainstacks to quickly switch between different ones. Mode 0 stacks are not included in the list. IDE stacks or mode 0 stacks can be specified by typing the stack name in the field.

The Prefs substack provides all of the options available for the currently tracked stack and the Script Tracker overall. Changes are saved when the tab is changed or the window is closed. The overall preferences are saved in the same location as the LiveCode prefs (but in a separate file). Stack level preferences are stored in each mainstack as a custom property set.

The Log will provide the time taken for an export and list each file that was touched. Some error messages will get displayed there.

Brian, you're such an asset to our community. Thank you for this. I know someone who really, really needs this. His current app is a maze of libraries and stack-only scripts that disrupt the message path to the point where it's difficult to find where errors occur. This will allow him to go back to a more standard message hierarchy in the binary stack while still tracking the project in git.

As someone who occasionally needs to advise on this project, I salute you.

I just posted an update that uses textEncode/textDecode to ensure scripts are saved in UTF-8.
I also modified the script menu so that the alt key can be used to include IDE stacks (still hides mode 0 stacks which should keep the script only stacks off the list).

@Brian, I just got a moment to try Script Tracker. I have a stack I've been working on for a long time. I made some changes to it recently. Suppose I want to see how the changes I just made compare to the way it was before I had Script Tracker. Is there a way to grandfather in an older version so I can compare it to the newer one?

I'm not a git guru so I'd like to compare two text files in BBEdit. If I export scripts from the old copy, and then export scripts from the new copy, will the second set of files overwrite the original set? I don't want to import any files, only see the differences. You mentioned that syncing is automatic, but I don't want my current version to change.

Edit: I guess I could just move the first set of files out of the folder before creating a second set. I'm also not clear on how diff files work or how much info they contain. Are they cumulative over several updates? (Git novice here.)

Thanks Brian, i had to look first to get the idea.
It's an automatic version of what i do manually, which costs more time.
I mostly copy every piece of script in a text file with notepad++, and save it seperately, so i have to open every used element which contains a script and copy it.
I like to have it as a text file so i can view/copy it quickly in notepad++ to livecode again if i need it.

Is there a way to grandfather in an older version so I can compare it to the newer one?

There isn't a built in easy way to do a compare like you are asking, but working on copies it would not be very difficult to do.

If you just need a one-time diff between the code it two stack versions, it will be pretty easy.

Create a folder and place a copy of the latest version of the stack inside

Use Script Tracker to export the scripts ("Sync Scripts")

Replace the stack with a copy of the old version

Open the old stack in LC

In the Script Tracker prefs, Change the stack collision policy to "Script" (won't make changes to the stack scripts)

In the Script Tracker prefs, Change the options/diff context the the number of lines desired (this will be the number of lines before/after any change that are included in the diff file)

Close the prefs window to be sure they are changed (switching to another tab also saves)

Click the "Sync Scripts" button

This will generate a single diff file (in the diff folder) that contains all of the differences between the two stacks. It doesn't list new scripts or removed scripts though (I suppose I could add that). If you want to flip the + and -, then do the same process but use "File" for the collision policy.

If I export scripts from the old copy, and then export scripts from the new copy, will the second set of files overwrite the original set?

On every export, Script Tracker will update the list of files and remove extras. So if you export from the old stack it will "update" everything that is different. But it will also see everything as a collision since it will think the script changed and the file is newer.

I have a Mac program called "DeltaWalker" that makes it easy to compare 2 or 3 files to see how they have changed. It can also compare 2 folders and let you then look at the individual changes. Using something like that, you would just need to put the old stack into a fresh directory and export the scripts. Then you could compare the 2 script folders (current and old).

I'm also not clear on how diff files work or how much info they contain. Are they cumulative over several updates? (Git novice here.)

Script Tracker creates a diff for each sync operation (named with the seconds). Not nearly as useful as Git, but is mainly there to allow a quick check of what changed on a particular sync.

If you are going to actually use Git, then it gets easier in the future. Every time you perform a commit in Git, a full snapshot it stored. At any time you can obtain a delta between any 2 points in the history. Works great for text files (can tell exactly what changed in each file), not so much for binary (where you can just see that there are different files, but not what changed).

Going backward to before you started tracking the project in Git would be difficult. But you could build a history with a little bit of effort when you start tracking. Basic process would be to take the oldest version and export the scripts and do an initial commit with a note for that particular version. Then, wipe the scripts directory and do the same for the next version. Git will be able to detect changes so you just select everything and do a commit each time. It would be tedious, but you could end up with a history like that. Even though Git can't provide useful information about a binary stack, you could still commit it with each version to have an archive copy (that's what I'm doing). You don't get any of the benefits of Git's compression though, so it will make the repository grow quicker.

Thanks Brian. A one-time diff is all I need right now. I made some changes that don't all work, so I want to remove some of them. They are scattered around the stack so a diff file will be useful. I'll give your instructions a try. I'm storing all your posts for reference.

Some day I'll try to learn git, but the effort is more than I have time for right now. I know it's a powerful and useful tool, but it's also complex and nerdy. I even got lost in GitHub which is supposed to be the "dummies" interface.