Nathan Hartman wrote:
> Some thoughts (probably too many)...
Not at all, this is fantastic, right where I want us to be, and very
helpful.
> I agree that 'init' and 'finish' should happen automatically.
> [...] As for when the 'finish' should occur, [...] probably not
> until the results have been squashed and committed.
>
> As far as what to name the commands, if the "checkpoint" command is
> changed to "local" and the "save" subcommand is changed to "commit" then
> you get:
>
> 1. svn local commit
> 2. svn local revert
> 3. svn local rollback
> 4. svn local list|log
> 5. svn local squash
> 6. svn commit <--- to the central repository
>
> I think users will immediately start getting ideas about what this
> means. Is that a good thing? It depends on what the goals are for
> checkpoints, how checkpoints are intended to fit into the larger
> workflow, and strategy for the future in general.
Excellent: this shows really clearly one way of thinking about
checkpointing.
> If checkpoints are intended to be merely a convenience with a limited
> purpose, then I would call the command "checkpoint" and "checkpoint
> save" to avoid confusion and make documentation, teaching, and learning
> easier.
>
> If checkpoints are intended to have a much wider application, eventually
> providing an answer to git's/DVCSs' ability to work offline and/or to do
> personal work on projects to which one lacks commit privileges, then I
> would use the shorter "local" [...] and try to keep the sub-sub-commands
> as close in semantics and function as possible to Subversion's original
> command set.
Agreed.
> [...] Working on the
> local machine essentially means working on a private branch. With that
> in mind, to answer questions such as: whether a status or diff should be
> against the original base or against the checkpoint, such questions
> should always be answered consistently with how server side operations
> are carried out today.
Agreed.
> [...] if this feature is supposed to have such broad scope [...]
> users will have immediate sky-high expectations [...]; if that
> kind of future appeals to enough people, then the present work should
> [maintain] such a parallel between this new "local branching" and the
> original server-side branching.
All considered, it feels to me like we have neither the collective will
nor the resources to take this in the direction of full local branching.
I can't commit myself to that. The present work should strive to keep
that option open, largely because a successful open-source software
system is one that others can adapt to their needs later on.
Rather, for me, this line of thought helps to clarify the differences
between what we are and are not creating.
> Some more thoughts...
>
> (1) It will eventually be necessary to create a new "URL specifier" or
> some sort of syntax to direct an operation into the checkpoint repo.
> This will make it possible to diff between any permutation of working
> copy, central repository, and local checkpoints, which will be crucial
> once users begin to use checkpoints as local branches. I can see a use
> case where a 3-way diff between all three is useful.
I'm not yet sure how important is diffing (2-way and 3-way) between
central repo and checkpoints. If we treat checkpointing as intermediate
WC states rather than as local branching then providing a syntax for
these kinds of operation is arguably less important. It still would be
of some use, just as 'rBASE' is useful, but not that 'rWORKING' has
always been missing from the UI despite a filed request for it, so there
is no syntax to request "diff -rWORKING:BASE" for example.
> (2) [...] "svn update" should perform an automatic implicit
> "checkpoint save" [...] If an update turns ugly, you will be able to do
> that 3-way diff I was just talking about.
Or you could revert the update. Yes, I would love to have this feature too.
Performing an 'update' with a checkpoint series is a bigger ask than it
might at first seem. In effect, it requires rebasing the series of
checkpoints on the new base, which gets ugly because of the need to
handle conflicts (which is ugly enough already in the existing
single-depth WC).
Initially, I suggest 'update' and 'switch' will be incompatible with
checkpoints. The user must first squash the checkpoints.
As an enhancement, on running 'update', Subversion could 'squash' the
checkpoints and shelve the resulting patch (but without reverting the
WC). That would be enough to allow better manual 'undo' if the update
went badly and if the user can remember the previous base state
(revision/revisions). If the shelving function would also save a
description of the base state, so much the better.
I do intend to give more thought to the more advanced possibilities in
this direction, though, like rebasing, just to see what it leads to.
> (3) Eventually, squashing should be optional;
By which you mean it should be possible to replay all the local commits
separately. Yes, but only if we go that route (as discussed above).
> that said, it's not
> feasible to checkout a WC from a trunk that has lots of activity on it,
> work locally for weeks, and then expect to replay the local commits onto
> the trunk successfully. So I suggest this alternative: You can checkout
> a working copy and make as many checkpoints as you want. When ready to
> commit, one of the following happens:
>
> (a) you squash, update, and commit [...]
>
> (b) you can replay the commits to the server only if no other
> commits have been made in the meantime [...]
>
> (c) you do not wish to squash but further commits have happened in
> the originating directory on the server, so you have the third option:
> create a new branch on the server and replay your commits onto that branch
That option (c) to replay the checkpoint commits onto a new branch is a
good thought.
It reminds me of "git stash branch <branchname>" which creates and
switched to a new (local) branch based on the stash's recorded base, and
pops the stash, thus guaranteeing there will be no conflicts or surprises.
It also reminds me too of Perforce's shelving: changes are 'shelved' on
the server, and another user can inspect or unshelve them, which is
useful as a way of reviewing other people's changes and for passing work
in progress from one user to another.
> I don't know if I'm making any sense here, but the reasoning is this: If
> you're on the train to work and you make three checkpoints, you can use
> option (a), squash, update, and commit. If you're working on a private
> local branch and you make 300 checkpoints, then you can use option (c)
> to "move" your checkpoints from the local machine to a new branch on the
> server. This clears the checkpoints from your local machine and brings
> your WC up to date with the HEAD of that new branch. Now, you can
> continue working, make 300 more checkpoints, and (since no one else is
> working in that new branch, (hopefully!!)), you can subsequently use
> option (b) to continue replaying your checkpoints onto that branch.
Yes, an in addition you can merge your branch back to its parent (e.g.
trunk) and so preserve the history of your checkpoints in the repo (if
that's what you wanted to do) without cluttering trunk's history.
On the negative side, this starts to go in the direction of preparing a
series of committable patches: see below about log messages.
> [...] I suggest ability to specify a log message [...]
A log message option is intentionally omitted for now. My thinking is
that specifying a log message reinforces the idea that each checkpoint
commit will eventually become a central-repo commit, and with that in
mind, the user's expectations would be a little different. They might
try to make each checkpoint commit a self-contained, logical, complete
change with a formal log message. Then they might expect to be able to
go back and modify an earlier local commit to correct mistakes in it
rather than apply the corrections in a follow-up commit, as surely
that's one of the primary benefits of local commits (second only to
being able to do it offline). In other words, the expectation of
creating a 'patch series' in the sense of 'Quilt', with an emphasis on
easily re-basing the later patches in the series after modifying an
earlier one.
> I think that's about it for now. Hopefully these thoughts are helpful,
> not overwhelming. ;-)
Totally, this is exactly the level I want to be discussing!
- Julian
Received on 2017-07-28 14:19:18 CEST