On Thu, Jul 27, 2017 at 7:56 AM, Julian Foad <julianfoad_at_apache.org> wrote:
> What can we learn from this mock-up? Here are some of my thoughts
(snip)
> If I checkpoint my changes, do I then want to see 'status' and 'diff'
>
against the original base or against the checkpoint? Both are useful.
>
(snip)
> Probably 'checkpoint init' should not be needed, and instead running
> 'checkpoint save' should initialize the checkpointing repo if not
> already done.
>
> Probably 'checkpoint finish|uninit' should not be needed, and instead
> should happen automatically when the user either commits or reverts the
> entire set of changes.
>
Some thoughts (probably too many)...
I agree that 'init' and 'finish' should happen automatically. Creation and
destruction of a hidden repository (or any data structure) is an
implementation detail that could change in the future and should not be
leaked. As you've already said, the 'init' should occur the first time a
checkpoint operation is done. As for when the 'finish' should occur, that
is a question I've been grappling with... I would say, 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.
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" (unless someone can think of a better,
shorter, and more descriptive name) and try to keep the sub-sub-commands as
close in semantics and function as possible to Subversion's original
command set. Even though the word "local" is technically a command, we
pretend it's more of a mode specifier that redirects what would normally be
server side operations to the local machine instead. 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. Of course, if this feature is supposed to have such broad scope,
there is the (not insignificant) issue that users will have immediate
sky-high expectations that will take significant additional time and effort
to fulfill, so clearly this is not by any means an immediate goal; it's a
*possible* future direction, and if that kind of future appeals to enough
people, then the present work should try to be compatible with that future
by maintaining (to the extent possible) such a parallel between this new
"local branching" and the original server-side branching.
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.
(2) Once checkpoints are working reliably, I suggest that "svn update"
should perform an automatic implicit "checkpoint save" (or whatever the
command is called) before attempting to fetch from the repository and merge
with the working copy. This will add a big safety net to what can be a
dreaded process. If an update turns ugly, you will be able to do that 3-way
diff I was just talking about.
(3) Eventually, squashing should be optional; 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 (which will turn into an infinite
loop if item #1 above is implemented and update creates a checkpoint...
hmmm... not good)
(b) you can replay the commits to the server only if no other commits
have been made in the meantime (to trunk or whichever directory originates
the checkout)
(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
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.
There was one other thing... Oh yes. For "checkpoint save" or "local
commit" or whatever it ends up being called, I suggest ability to specify a
log message with -m or -F just like a normal commit. But for a checkpoint,
unlike a normal commit, I would make a log message optional; if not
provided, one is generated automatically.
I think that's about it for now. Hopefully these thoughts are helpful, not
overwhelming. ;-)
Received on 2017-07-27 17:55:49 CEST