On Tue, Jun 25, 2019 at 1:15 PM Thomas Singer <thomas.singer_at_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? :-)
Received on 2019-06-28 18:29:32 CEST