Snapshots / Revisions mode

An optional feature that when enabled would capture a copy of the current buffer (or any modified buffers) each time a run happens. The copies would be stored in a default or user specified location, named and ordered in a clear manner like buffer-<N>-<timestamp>-run-<M> for example.

This feature alone would be useful for having some basic revision control during coding sessions and being able to roll back to prior states of the code. Another use would be having full ‘transcripts’ of live coding sessions - allowing one to see the progression of changes from starting script to end as well as being able to recreate key moments of the session for further listening or exploration.

Naturally, having some UI support for viewing revision lists and loading revisions would be huge for usability but the saving support alone could be useful for many. Technical users should be able to achieve a similar system by wrapping a little supporting code around sonic-pi-tool

I think that everything you do is already recorded in a git repository in the .sonic-pi/default folder
This contains the latest versions of the 10 buffers, and the cached samples folder, but if you try
ls -al in the default folder you will see something like

drwxr-xr-x  15 rbn  staff    480 26 May  2017 .
drwxr-xr-x   4 rbn  staff    128  8 Aug  2016 ..
-rw-r--r--@  1 rbn  staff  10244 14 Oct 22:51 .DS_Store
drwxr-xr-x  11 rbn  staff    352 13 Nov 17:36 .git
drwxr-xr-x  39 rbn  staff   1248  9 Jun 15:32 cached_samples
-rw-r--r--@  1 rbn  staff   2295 10 Nov 15:55 workspace_eight.spi
-rw-r--r--   1 rbn  staff   2494 10 Nov 15:55 workspace_five.spi
-rw-r--r--   1 rbn  staff   8203 10 Nov 15:55 workspace_four.spi
-rw-r--r--   1 rbn  staff   8597 10 Nov 15:55 workspace_nine.spi
-rw-r--r--   1 rbn  staff   1263 10 Nov 15:55 workspace_one.spi
-rw-r--r--   1 rbn  staff   8273 10 Nov 15:55 workspace_seven.spi
-rw-r--r--   1 rbn  staff   1287 10 Nov 15:55 workspace_six.spi
-rw-r--r--   1 rbn  staff     50 10 Nov 15:55 workspace_three.spi
-rw-r--r--   1 rbn  staff   2202 12 Nov 16:41 workspace_two.spi
-rw-r--r--   1 rbn  staff   5719 10 Nov 15:55 workspace_zero.spi

and if you try git log
you will find that it contains a complete record of all the changes made.

eg

Robins-MacBook-Pro-2:default rbn$ git log
commit ea861dd8279707a8a87fa5385c4d7b56671426af (HEAD -> master)
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
Date:   Tue Nov 12 16:41:36 2019 +0000

    v3.2.0-dev-740c7 -- 9a39d850-9f4e-43dc-97a2-90733463404c --  :~: Autosave Workspace workspace_two.spi

commit a4781d744d79bf74f6e98225f8d7bcf02a182923
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
Date:   Tue Nov 12 16:41:27 2019 +0000

    v3.2.0-dev-740c7 -- 9a39d850-9f4e-43dc-97a2-90733463404c --  :~: Autosave Workspace workspace_two.spi

commit fdd58e24138f19644a84d13991ee57f55bfe1db6
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
Date:   Tue Nov 12 16:41:15 2019 +0000

    v3.2.0-dev-740c7 -- 9a39d850-9f4e-43dc-97a2-90733463404c --  :~: Autosave Workspace workspace_two.spi

commit 44816e0c407276ec38ad5bb480871f1aeec559d4
Author: Sonic Pi Autosave <autosave@sonic-pi.net>
:

(You can press enter to see further entries, or q to exit)
Of course, to use it easily you would have to develop this, but I have on occasion retrieved stuff from a buffer that I have accidentally deleted, using standard git commands.

2 Likes

That’s great! I can’t tell at a glance, but it looks like these might be correlated with run events (based on my log and recent activity). I wonder if auto-saves happen any other time; if so, tagging the commits could help differentiate the source of the save operation.

Thank you @robin.newman

The automatic git commits are only triggered when you hit run :slight_smile:

1 Like

One of my early experiments as a Sonic Pi developer was exploring the implementation of a Sonic Pi ‘History browser’. This basically displayed a simplified graph UI allowing folks to navigate through the revision (commit) history and easily browse particular versions, optionally tag them with custom labels, and reload and/or branch off them for further adaptation.
Given that I had done hardly any C++/Qt development before at the time, (and I’m still not highly experienced at it these days either) what I managed to build was hugely inefficient and took far too long to load things etc - so I basically gave up on that idea.
I would still definitely be interested in building something like this, but would either need help to find and/or build a suitable approach, or time to be able to learn more and find out one for myself :sweat_smile:

3 Likes