On Fri, Jul 28, 2017 at 8:19 AM, Julian Foad <julianfoad_at_apache.org> wrote:
> Nathan Hartman wrote:
> 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.
>
Agreed. Just to emphasize, I don't suggest going the route of full
local branching today. That involves challenges that require some
serious thought, not only implementation but also user perspective:
making it easy to learn and easy to use, like the rest of Subversion.
> > (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).
>
Why does update with a checkpoint require rebasing? There must be a
large gap in my understanding here. Forgive me if I misunderstood, but
I thought a checkpoint is a snapshot of what the working copy looked
like at the time it was taken, to provide a sort of high-level
undo/redo capability. Suppose I did a checkout at 8:00 AM and then did
some work, taking snapshots of what my working copy looked like at
9:00 AM, 11:00 AM, and 2:00 PM. At 2:30 PM I invoke svn update. I
would expect to end up with four snapshots: 9:00 AM, 11:00 AM, 2:00
PM, 2:30 PM; and I would expect the working copy, after the update, to
be the same as though I checked out at 8:00 AM, worked until 2:30 PM,
and did the update, exactly as it occurs today. In other words, I
would expect my snapshots to remain untouched and I would expect the
update to be the "next step" in the working copy contents' linear
evolution. I could potentially continue working and taking snapshots,
and make subsequent updates as well. The implementation would probably
have to record the BASE at the time of each checkpoint, so that if you
rollback to it, passing through an "update" point, it could restore
that as the working copy's BASE along with restoring the working
copy's contents to those of the snapshot.
> Initially, I suggest 'update' and 'switch' will be incompatible with
> checkpoints. The user must first squash the checkpoints.
>
Agreed. This is reasonable for a first implementation.
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 don't like the idea of mixing checkpoints and updates with shelving.
It seems too kludgy to me because shelving is a way to temporarily
interrupt work and come back to it later, whereas updating is a linear
step forward, not an interruption. I propose this alternative: "svn
checkpoint squash" will in effect discard all checkpoints and take a
new checkpoint of the working copy. Following my earlier example of
four checkpoints, if I squash at 4:00 PM, I'll end up with just one
checkpoint with the 4:00 PM timestamp, identical to my working copy.
If "update" performs this squash operation (or simply takes a
checkpoint if none exists), then I believe it's a more logical
solution.
> > [...] 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.
Fair enough. I'm in 100% agreement that this implementation should
focus on simplicity and reliability.
Received on 2017-07-28 17:11:13 CEST