Ability to automatically save versions to source code, rollback versions and see time-stamped history #4375

Increasing Access

The ability to automatically save versions, roll back code, and view a timestamped history in the p5.js Web Editor could be a game changer for educators because it turns coding from a fragile trial-and-error experience into a process students and teachers can review, understand, and learn from.

For educators teaching beginners, this solves several persistent problems.
7 reasons this could be a game changer

1. Students can experiment without fear of breaking their work.

Beginners often hesitate to change working code because they don't know how to recover if something goes wrong. Automatic versioning removes that fear.

• Try changing a variable, loop, or function.
• See what happens.
• If the sketch breaks, roll back to a working version.
  Educational impact: Students become more willing to experiment, make mistakes, and learn through discovery.

2. Teachers can see how a student solved a problem, not just the final result.

A finished sketch tells you what a student produced, but not how they got there. Timestamped versions can reveal the evolution of their thinking.

• Did they build the sketch incrementally?
• Did they try several approaches to solve a problem?
• Can they identify when a bug was introduced?
• Did they understand the changes they made?
  Educational impact: It creates a window into the learning process, not just the final deliverable. Version history alone won't prove who wrote the code, but it can provide useful context for assessment and conversations with students.

3. Teachers can help students debug more effectively.

Imagine a student says, "My sketch was working yesterday, and now nothing works."

Without version history, the teacher and student may have to reconstruct the problem from scratch. With it, they can step backward through the code and find the change that introduced the bug.

Educational impact: Debugging becomes a teachable process instead of a frustrating guessing game.

4. It makes teaching programming concepts more concrete.

Teachers could use a student's own coding history to demonstrate how programs evolve.

For example, a student starts with a single circle, adds variables to control its position, introduces a loop to create a pattern, and then adds conditionals to change the colors.

The teacher can compare each stage and ask: What changed? Why did the behavior change? What did the loop make possible?

Educational impact: Students see the relationship between a code change and its visual result. This is especially valuable in creative coding, where the output is immediately visible.

5. It reduces the risk of lost work and wasted class time.

Beginners frequently overwrite working sketches, delete code accidentally, or make a series of changes they don't know how to undo.

Automatic saving means students don't have to remember to create backups or understand Git just to protect their work.

Educational impact: Less time recovering lost work, more time learning programming.

6. It gives educators a better way to assess progress.

Version history could help instructors distinguish between a student who reached a solution through gradual experimentation and one who submitted a final result they cannot explain.

It could also help teachers identify students who are struggling early, based on patterns such as repeated failed attempts or difficulty making incremental progress.

Educational impact: More informed feedback and a stronger basis for formative assessment, without requiring students to learn professional version-control tools.

7. It creates a natural introduction to professional development practices.

Once students become comfortable with saved versions, they can begin to understand concepts such as checkpoints, change history, recovery, and comparing revisions.

Later, those concepts can provide a bridge to Git and more advanced development workflows.

Educational impact: Students learn good development habits without facing the initial complexity of a separate version-control system.

Feature request details

This could be implemented in a fairly lightweight manner in conjunction with the auto-save feature. When you save the source code in the auto-save, also save a diff that could restore to the prior version. "patch" and "diff" are linux utilities that can be easily used or imitated to achieve this functionality. As the file changes over time, keep each diff. (maybe the diffs can be kept in a hidden folder of the project). Someone can recreate an old version using a command in the editor that will patch the current file to bring it back to the previous one. The timestampe of the diff files can mark the time of the change.