> On Jun 28, 2019, at 12:29 PM, Nathan Hartman <hartman.nathan_at_gmail.com> wrote:
>
>> 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? :-)
I'd maybe welcome the feature but it wouldn't change much for me as this was never an area of SVN where I felt much pain. For me the problem would be that this is all still built upon a base that does not handle merging or moved files very well. Problems that would mean this feature would also likely suffer from those weaknesses when trying to reconcile your local checkpoints with what has happened upstream as you are pulling in updates. While I can see how this could also aid in the code review options, I think the fact that the Git model is based on reviewing actual commits is still superior because the commit you review is the one that you know is merged/accepted. For this feature it is still just a form or reviewing a patch and there is no real way to verify that what you reviewed is what was merged. At minimum, those are problems that would still need to be solved to claim we are nearing parity with what Git can offer here.
More importantly, I still think this is a question that is bigger than features. For the community to become healthy we need something that is going to bring 5-10 regular contributors or maybe a smaller number if there is a big increase in short term contributors. This shelving/checkpointing idea/feature has been around for years. There has been some interest in trying the work in progress but it has not brought in anyone to actually contribute. There has not even been many comments to emails on the proposals that Julian has made.
While it is great to be excited about what the product might look like AFTER someone does all of this work the real question needs to be what is going to draw in more people to contribute. I am not sure there is anything that will do this.
Mark
Received on 2019-06-28 18:48:57 CEST