On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer <thomas.sin...@syntevo.com> wrote:
> What I like most about Git: > - it allows to create clean commits, because I can modify all my local > commits, e.g. reorder and squash them, in case I detected an error in a > previous, unpushed commit > <snip> > - I can solve every conflict locally, try again and again, without > losing any changes (imagine a complicated merge in SVN where you now > have solved a couple of conflicts, but an update brings new conflicts) > <snip> > - Git allows me to create a feature in my own branch, turn all my > commits in this branch up-side-down if I need (even after pushing to the > repository) and finally rebase it on top of the main development branch > Let's put our "future caps" on... Imagine a fully-functioning checkpointing feature: Checkpointing is a "local commit history" mechanism, but we don't call it a "commit" because "commit" is a strong concept in Subversion. Commit history is immutable: Whatever is committed is safe forever. A checkpoint is a weak concept, more like the weak commit history you find in a DVCS. Checkpoints are local and private until committed or shared. A checkpoint can represent any committable changes. Checkpoints can be rewritten, modified, reordered, copied, moved, squashed, divided, deleted, etc. Their commit messages can be edited easily. Checkpoints live in arrays of checkpoints. Each array has a user- assigned descriptive name and serves as a mutable linear mini-history. Arrays can be copied, renamed, deleted... You can have as many arrays as you like. Checkpoints and arrays of checkpoints can be created and manipulated by the system or the user. By the System: Automatic checkpoint before potentially destructive operation: If there are uncommitted changes in the WC, svn update and svn merge automatically create a checkpoint. That way, the user never loses a good working state to a bad one if the update, merge, or ensuing conflict resolution get messed up (by either the system or user). You can try again and again until you get it right. Automatic checkpoint at specified time intervals: This one is more applicable to GUI clients. You can tell it to make an automatic checkpoint, say, every 15 minutes, if there are new changes. Better yet, the GUI client could monitor the directory / get OS change notifications and make an automatic checkpoint of every change. So when you hit "save" in your editor, Subversion makes a checkpoint as well. Automatically. By the User: Reordering/rewriting/manipulating means you can work happily and make checkpoints along the way, ending up with a "messy" checkpoint history. You can rewrite/reorder checkpoints in place. Or, if you like "non-destructive editing," create a new separate array and cherrypick checkpoints onto it, making any edits. If you worked on different unrelated things, create different unrelated arrays and cherrypick each checkpoint onto the appropriate array. Once you've built up a clean linear history of related changes in a checkpoint array, that array can either be squashed and committed as one commit or left intact and committed as a sequence of commits. GUI clients could utilize Subversion's lock-modify-unlock feature to make the separate commits in order without other unrelated commits getting in the middle. In the future, a new improved client/server protocol will support committing an array of checkpoints as a sequence of commits, atomically. So either all the checkpoints go in or none go in, and nothing gets in the middle. Pull requests: A mechanism to pack up an array of checkpoints in a single file for sharing with colleagues. No big paragraph needed to explain this one. How does the future look so far? :-)