On Fri, Jul 28, 2017 at 8:19 AM, Julian Foad <julianf...@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.
