Re: Checkpointing

Imagine working on one larger feature (or even multiple features). You already have created a couple of local commits, but are not yet finished. Following use cases come to my mind: 1) some other developer commits new revisions - it should be possible to continue working on your feature-queue

Re: Checkpointing

On Sun, Jun 30, 2019 at 11:22 AM Thomas Singer wrote: > With "rebasing" I mean, that such list of "local commits" needs to be > re-applied (on demand, not automatically) onto a different revision. > Something like a continues series of cherry-picking (with the > possibility to get a conflict in e

Re: Checkpointing

On 30.06.2019 16:56, Nathan Hartman wrote: > On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej > wrote: > > As Mark explained, it will do none of the above unless someone > steps up > and writes the code. > > For reference, what Nathan described was discussed he

Re: Checkpointing

Hi Nathan, Thanks for your detailed answers. - will it support "rebasing" such a local history onto the latest updated commit? It will have to support "rebasing" which is what "svn update" already does today. Otherwise you couldn't commit your work! With "rebasing" I mean, that such list o

Re: Checkpointing

On Sat, Jun 29, 2019 at 7:21 AM Branko Čibej wrote: > As Mark explained, it will do none of the above unless someone steps up > and writes the code. > > For reference, what Nathan described was discussed here on the list and > in person during hackathons years ago, yet nothing happened until Juli

Re: Checkpointing

On Fri, Jun 28, 2019 at 1:12 PM Thomas Singer wrote: > - so the working copy can have checked out multiple commits or one > checkpoint? > The working copy has always provided one "view." I say "view" for lack of a better word but I mean the checked out directory of your data that is under versio

Re: Checkpointing

On 28.06.2019 19:12, Thomas Singer wrote: > Hi Nathan, > > Thanks for your explanation. This sounds quite interesting. I have > some questions though: > > - so the working copy can have checked out multiple commits or one > checkpoint? > > - will it support multiple histories ("branches") planned,

Re: Checkpointing

Hi Nathan, Thanks for your explanation. This sounds quite interesting. I have some questions though: - so the working copy can have checked out multiple commits or one checkpoint? - will it support multiple histories ("branches") planned, e.g. for different features? - will it support "r

Re: Checkpointing v1 design

Julian Foad wrote: [...] This aims to streamline the manual method, which I use myself, of using 'svn diff' and 'svn patch' to create and apply patches named 'feature-v1.patch', 'feature-v2.patch', etc. Now on trunk: $ svn help | grep "shel[fv]" shelf-diff shelf-drop shelf-list (she

Re: Checkpointing v1 in diagrams

And here are the said diagrams... Julian Foad wrote: Here are a couple of diagrams to show how Checkpointing v1 behaves so far. 1. Shelve, Unshelve Shows a difference between how Shelving-v1 worked and how it works in the new sheving-and-checkpointing design. Note that Unshelve no longer del

Re: Checkpointing v1 design

Julian Foad wrote: [...] This aims to streamline the manual method, which I use myself, of using 'svn diff' and 'svn patch' to create and apply patches named 'feature-v1.patch', 'feature-v2.patch', etc. An initial version is now committed to 'shelve-checkpoint' branch. - Julian

Re: Checkpointing v1 design -- terminology

> > $ svn save --revert -v2 "add hair color to person page" >> >> .. does the save and THEN drops the CL and it's changes in working copy - >> back to no changes but not necessarily up to date. >> > > That sounds like you're proposing an alternative syntax for what the > 'shelve' command does -- ex

Re: Checkpointing v1 design -- terminology

On 10.11.2017 14:20, Julian Foad wrote: > Julian Foad wrote: >> [...] To achieve such rollbacks, the user would have to first revert, >> which involves deciding what to revert. >> >> And that seems OK to me. > > The larger point is that this kind of work flow, and the difficulty of > working with c

Re: Checkpointing v1 design -- terminology

Julian Foad wrote: [...] To achieve such rollbacks, the user would have to first revert, which involves deciding what to revert. And that seems OK to me. The larger point is that this kind of work flow, and the difficulty of working with changes in overlapping subtrees, is analogous to some

Re: Checkpointing v1 design -- terminology

Paul Hammant wrote: I'd be happier with save-cl rather than ci-save.  Or just 'save', as I'm not sure what you're saving if not a change list.  Incidentally CL looks pretty close to CI in lower case and that's already used. Spaces allowed in FOO name? $ svn save -v2 "add hair color to person

Re: Checkpointing v1 design -- terminology

Julian Foad wrote: You can work out the 'rollbacks' from there (I haven't time right now); (That sounded like a crass cop-out, but I seriously didn't have a moment more to spare to think about it right then.) The 'rollback' commands as written in steps 6 and 7 would both error. To achieve s

Re: Checkpointing v1 design -- terminology

Branko Čibej wrote: I shudder to think of the interactions and side effects of partial checkpoints. Consider our standard Greek tree and the following sequence: First think about saving checkpoints the manual way, to set our initial expectations fairly low: svn diff foo-paths > foo-4.patch

Re: Checkpointing v1 design -- terminology

On 07.11.2017 16:15, Julian Foad wrote: > Branko Čibej wrote: >> On 06.11.2017 17:30, Julian Foad wrote: >>> The key point I am making here is the "topic" we're talking about in >>> these commands is the "changelist" rather than the "savepoint" which >>> is merely a stored version of a changelist.

Re: Checkpointing v1 design -- terminology

Branko Čibej wrote: On 06.11.2017 17:30, Julian Foad wrote: The key point I am making here is the "topic" we're talking about in these commands is the "changelist" rather than the "savepoint" which is merely a stored version of a changelist. All our current commands that use changelists use th

Re: Checkpointing v1 design -- terminology

On 06.11.2017 17:30, Julian Foad wrote: > The key point I am making here is the "topic" we're talking about in > these commands is the "changelist" rather than the "savepoint" which > is merely a stored version of a changelist. All our current commands that use changelists use them as an alias for

Re: Checkpointing v1 design -- terminology

I'd be happier with save-cl rather than ci-save. Or just 'save', as I'm not sure what you're saving if not a change list. Incidentally CL looks pretty close to CI in lower case and that's already used. Spaces allowed in FOO name? $ svn save -v2 "add hair color to person page" Also.. $ svn sav

Re: Checkpointing v1 design -- terminology

Julian Foad wrote: 'Roll back' means retrieving an old version of a shelved change and could be named like one or a permutation of these:   svn unshelve --checkpoint=3 foo   svn shelf restore foo@3   svn revert --savepoint=3 --cl=foo   svn changelist restore -v3 foo (I am deliberately brin

Re: Checkpointing v1 design -- terminology

Branko Čibej wrote: [...] I've often wished we'd made our argument parser slightly more flexible in that respect, so that [...] we could write     svn [topic] command [options args] FWIW, the reason I'm slightly in favour of "savepoint" vs. "checkpoint" has been discussed before: the abbrevi

Re: Checkpointing v1 design -- terminology

Branko Čibej wrote on Sat, 04 Nov 2017 13:51 +0100: > Traditionally we've striven to appear marginally literate in the text we > produce, that includes command structure. There's no harm in trying to > adhere to that tradition, especially as it does not cost us more than > some chattering on the de

Re: Checkpointing v1 design -- terminology

On 04.11.2017 00:21, Daniel Shahaf wrote: > But I don't understand what's the problem that we're trying to solve > here. Why is it a problem that "shelf" is a noun and "shelve" a verb? > And for that matter, why couldn't we use "checkpoint" as a verb? Traditionally we've striven to appear margina

Re: Checkpointing v1 design -- terminology

On 03.11.2017 22:51, Julian Foad wrote: > Branko Čibej wrote: >>>    * main commands are 'checkpoint' to save a new version and >>> 'rollback' to revert to version N >> >> The main issue I have with this is that "checkpoint" is not a verb. (I >> know, neither are 'changelist' or 'auth'). >> >> How

Re: Checkpointing v1 design

On 2017-11-03 19:39:51 +0100, Branko Čibej wrote: > On 03.11.2017 15:54, Julian Foad wrote: > > After playing with two pre-prototypes and discussing a wide variety of > > ideas on this list, I have given detailed thought to a v1 > > checkpointing design with the following properties: > > > >   * lo

Re: Checkpointing v1 design -- terminology

Julian Foad wrote on Fri, Nov 03, 2017 at 21:51:37 +: > Branko Čibej wrote: > > >   * main commands are 'checkpoint' to save a new version and > > > 'rollback' to revert to version N > > > > The main issue I have with this is that "checkpoint" is not a verb. (I > > know, neither are 'changeli

Re: Checkpointing v1 design -- terminology

Branko Čibej wrote:   * main commands are 'checkpoint' to save a new version and 'rollback' to revert to version N The main issue I have with this is that "checkpoint" is not a verb. (I know, neither are 'changelist' or 'auth'). How about 'save' (to create a savepoint) and 'restore' instead?

Re: Checkpointing v1 design

On 03.11.2017 15:54, Julian Foad wrote: > After playing with two pre-prototypes and discussing a wide variety of > ideas on this list, I have given detailed thought to a v1 > checkpointing design with the following properties: > >   * local (not server) >   * built on shelving v1 (patches) >   * ma

Re: Checkpointing v1 design

Listing shelved and applied change-sets could look something like this: [[[ $ svn shelves applied: X (at version 1) thing (at version 10) shelved: foo (1 version) bar (4 versions) old-thing (1 version) new-changes (18 versions) ]]] or integrated with changelists: [[[ $ svn changelis

Re: Checkpointing mock-up option 3 (backed by a local repo)

On Tue, Aug 1, 2017 at 9:19 AM, Julian Foad wrote: > Keep in mind that a revision -- or any versioned state -- can be > thought of in two ways: as a complete snapshot of the tree, or as > representing a change relative to the previous snapshot. > > First let us be sure we understand that updating

Re: Checkpointing mock-up option 3 (backed by a local repo)

Nathan Hartman wrote: > Julian Foad wrote: > 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 i

Re: Checkpointing mock-up option 3 (backed by a local repo)

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

Re: Checkpointing mock-up option 3 (backed by a local repo)

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 bee

Re: Checkpointing mock-up option 3 (backed by a local repo)

On Thu, Jul 27, 2017 at 7:56 AM, Julian Foad 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 'ch

Re: Checkpointing mock-up option 3 (backed by a local repo)

What can we learn from this mock-up? Here are some of my thoughts. * Status and diff against last incremental change vs. against the 'commit base'. * The 'init' and 'finish' work flow should be simpler. * s/w architecture: exporting from WC, changing the WC base, ... == Status and diff against

Re: Checkpointing mock-up option 3 (backed by a local repo)

Nathan Hartman wrote: > Julian Foad wrote: > I committed an initial prototype for checkpointing backed by a local > repo embedded in the WC (the "option 3" design), on the > "shelve-checkpoint3" branch. > > http://svn.apache.org/r1803046 and follow-ups. > > Woohoo! Very exciting!

Re: Checkpointing mock-up option 3 (backed by a local repo)

On Wed, Jul 26, 2017 at 11:13 AM, Julian Foad wrote: > I committed an initial prototype for checkpointing backed by a local > repo embedded in the WC (the "option 3" design), on the > "shelve-checkpoint3" branch. > > http://svn.apache.org/r1803046 and follow-ups. > Woohoo! Very exciting! I didn

Re: Checkpointing - is not Quilt

Branko Čibej wrote: In order to use checkpoints as a sort of local commit, you do have to be able to push a series of commits to the server. You'd distinguish explicit checkpoints (with log messages) and implicit/automatic checkpoints; only the explicit ones would constitute separate commits. T

Re: Checkpointing - is not Quilt

On 17.07.2017 13:42, Julian Foad wrote: > Initially I wrote that 'checkpointing' should allow committing the > result either all at once or as a corresponding series of commits. > Having thought more, I believe the use case for a series of commits > falls out of scope. > > Definitions: > > Quilt: