Playground: history of snippet

Feature requests
1

Background:
Currently snippet (saved playground code) is saved on server, and version controlled with a version number, but there is currently no way to see what changed between versions. It should be helpful that users can see what has been changed between versions, especally when asking questions here with a playground.

Proposal:
A version list for each snippet, with title and description from here when a playground being saved:

with title and description from here
with title and description from here502×489 2.8 KB

Could be organized like the github commit list:
the github commit list
the github commit list823×707 43.1 KB

And a diff viewer between 2 versions with the monaco diff viewer, since monaco-editor is already part of playground.
monaco diff viewer
monaco diff viewer973×255 9.59 KB

2 Likes
2

Yes. Kind of relates to some of my comments and the discussion around the new version snippet.
I also think a way to relate to changes and a version history would be good. But may be needs to be restricted to ‘registered playgrounds’ (see topic and my suggestions). Some of these playgrounds have thousands of iteration (mostly all clumsy attempts) - or even, non-related to the original, serving just as a base from something completely different. You wouldn’t want to go through the list of changes in this case, would you? :sweat_smile: :dizzy_face:

Let me link this to:

…and add a +1 :+1: to your suggestion. TBD how to implement… :thinking:

1 Like
3

It sounds cool in theory.
But the playground is an open space for everyone.
And often they go in different directions, different people make new versions, and not always from the latest version, so it would end up being one big mess :sweat_smile:

At the very least, it’d require a full rework of how the snippets and versions are handled

2 Likes
4

I believe that’s the plan as per the link I added. There’s this project initiated by @RaananW which I believe is ongoing (is it?). Though, we are mostly inline here. Same as you, I couldn’t help but realize that this will not work without adding another ‘type’ of playground with a number of requirements and conditions to follow.

1 Like
5

That’s true.

I thought a little about it last night, and it could be done by adding a “lastVersion” property, creating a hierarchy / multiple “branches” per playground…
All existing playgrounds would still look like spaghetti though, or blank if the diff is created at save-time.

the protential structure would look something like this.

0

 1 - version #1, spawned from version #0
  2 - version #2, spawned from version #1
   10 - version #10, spawned from version #2
   50 - version #50, spawned from version #2
  3 - version #3, spawned from version #1
   5 - version #5, spawned from version #3
 4 - version #4, spawned from version #0
 etc

TL:DR;

1 Like
6

Yes, but I’m afraid that this alone will only solve part of the problem. The version hierarchy tells from which PG/sub-version it is based on BUT… it doesn’t tell about the content being still relevant towards the objective of the initial PG. So, in the end the ‘latest’ version PG is not necessarly the last improved version of the original. Could be something completely different. In this case (when searching for something in particular) the hierarchy/version history becomes useless.
Reason why I think it would be great to have another ‘type’ or ‘class’ of PGs. Registered, official, …? call it the way you want… Basically, the idea is that this type of PG could only be saved when logged-in, need to fill-in the information/description for update and as a rule/requirement would need to update or enhance the original PG for the purpose it has been created… In any case, this entire thingy will require :thinking:

Edit: I was thinking we could have may be something like this when saving a PG…

Sub-section Title:
Publish to official PG

  • Add a checkbox to ‘Publish to official’ (off by default)
  • When checking ‘official’ - - >

Alert_: You need to be registered to publish to the official channel.

Else, If logged in: “Logged in as @mawa”

Section title:
You are publishing a new version of “PG NAME” - “PG snippet”

Select:
Title: What is the Purpose of this new release ?

  • It’s a fix/update of the original
  • It features enhancements/new parts (–> add tags)
  • It’s an alternate version (–> new branch)

Description title:
Please make a description of changes (will be published in version history)

#Tags: (displays original tag(s) - add, remove)

  • Add/remove #tags (required for enhancement or alternate only)

Confirm and save as… :

  1. Save to official (only if you are certain this is a distributable - creates new version distributed)
    • or - -
  1. Save as a draft (creates a subversion tagged as ‘official’ but not distributed; you may edit from this sub-branch and save the last version for distribution)
7

My post was purely from a technical standpoint,
E.g. how a hierarchy and version diff viewer could be implemented with the current snippet/version setup, no regards to actual content of the PG. :smile:

Posts like these pop up once in a while.
As far as i recall, it’s been stated several times over the years, on different occasions, that there won’t be any kind of login system (nor file hosting for that matter) on the playground.
The team does not want to maintain or deal with issues related to these features.
They want to focus work on BabylonJs to keep making it better and stronger.
Everything surrounding it is kept as simple and as close to maintenance free as possible :+1:

8

Fair enough, I can appreciate that. Actually, I do :smile:

Yes, that’s true and I know that. But the purpose was to discuss new. You cannot exclude it right from the start or certain possible improvement will also ‘go with the wind :wind_chime:’ before they have even been stated. (My opinion only). :grin:

9

With the unregistered nature, each revision could be ordered by date and grouped by IP address

10

The history of a snippet has been keeping me occupied as well for quite some time.

I did reference it quickly in the blog post (point 10), and someone in the comments added the suggestion to create a diff, which makes perfect sense.

The playground improvement project is “on-going”, but is sadly lower priority to many other issues I want to tackle before the next major version is out.

One thing we won’t implement is a log-in system where people have their own snippets. this has many different reasons which we discussed many times before. However, we should be able to provide an “editor” hash to the original snippet creator, to prevent people from saving on top of an existing snippet, making the changes hard to follow. So it will be very similar to a git repository in that sense - you can fork and create your own snipept ID, but not save on top of an older existing snippet. This is “coming soon”, as all other playground improvements. So little time, so much to do :slight_smile:

4 Likes