Details

      Description

      When working on a collection of local changes, it is sometimes desirable to be able to checkpoint your work. The utility, of course, it not in the checkpointing, but in the fact that you can then restore the working copy to one of your previous checkpoints. Workarounds today generally come in the form of temporary branches (which aren't offline) or series of patchfiles. Subversion should offer a first-class feature to facilitate this use case.

        Issue Links

          Activity

          Hide
          cmpilato C. Michael Pilato added a comment -

          This is similar to an offline commit such as is offered by DVCS tools, but
          differs is some key ways.  First, an offline commit results in a new changeset
          and a working copy that appears as a) no longer modified and b) inclusive of
          that changeset.  A checkpoint does not result in a new revision identifier at
          all, and the working copy after the checkpoint appears exactly as it does
          immediately before the checkpoint.  The changesets which result from a series of
          offline commits can be merged/applied elsewhere willy-nilly.  The checkpoints
          we're talking about here are modeled as a stack of arbitrary depth from which
          some number of the most recent items can be popped to return the working copy to
          some checkpointed state, but we're *not* talking about allowing arbitrary merges
          of the diffs between checkpoints into the WORKING tree.
          

          Show
          cmpilato C. Michael Pilato added a comment - This is similar to an offline commit such as is offered by DVCS tools, but differs is some key ways. First, an offline commit results in a new changeset and a working copy that appears as a) no longer modified and b) inclusive of that changeset. A checkpoint does not result in a new revision identifier at all, and the working copy after the checkpoint appears exactly as it does immediately before the checkpoint. The changesets which result from a series of offline commits can be merged/applied elsewhere willy-nilly. The checkpoints we're talking about here are modeled as a stack of arbitrary depth from which some number of the most recent items can be popped to return the working copy to some checkpointed state, but we're *not* talking about allowing arbitrary merges of the diffs between checkpoints into the WORKING tree.
          Hide
          subversion-importer Subversion Importer added a comment -

          I think both this issue and the related 3625 "shelving" issue are going about it
          wrong.  I think this shelving/checkpointing needs to be stored on the server in
          a special place parallel to the real repository.  You get three benefits with
          this server side approach:  1. allows fellow developers to more easily obtain
          another's shelved changes to try it out on his machine  2. it can be versioned
          so each checkpoint can be diffed with another, reverted, etc.  3. if the
          developers hard drive crashes, the changes are safe on the server.
          

          Original comment by scastria

          Show
          subversion-importer Subversion Importer added a comment - I think both this issue and the related 3625 "shelving" issue are going about it wrong. I think this shelving/checkpointing needs to be stored on the server in a special place parallel to the real repository. You get three benefits with this server side approach: 1. allows fellow developers to more easily obtain another's shelved changes to try it out on his machine 2. it can be versioned so each checkpoint can be diffed with another, reverted, etc. 3. if the developers hard drive crashes, the changes are safe on the server. Original comment by scastria
          Hide
          stsp Stefan Sperling added a comment -

          Shawn, your set of requirements sounds like you simply want developers to use a
          branch in the repository, which would cover all of the points you raise. The
          whole idea of checkpointing is that it happens entirely within the client, so it
          can be done offline.
          

          Show
          stsp Stefan Sperling added a comment - Shawn, your set of requirements sounds like you simply want developers to use a branch in the repository, which would cover all of the points you raise. The whole idea of checkpointing is that it happens entirely within the client, so it can be done offline.
          Hide
          gstein Greg Stein added a comment -

          Yup. I just said the same in 3625. Storing on the server ignores the main intent of the design here.
          
          

          Show
          gstein Greg Stein added a comment - Yup. I just said the same in 3625. Storing on the server ignores the main intent of the design here.
          Hide
          ari Ari Maniatis added a comment -

          I do hope this feature makes it into 1.8 since it would be extremely useful
          (alongside the shelving idea which is closely related to this concept).
          
          I agree that it is essential this idea work completely offline. Also, has
          thought been given about whether a series of checkpoints result in a series of
          commits or just one commit. Pros to creating multiple commits:
          
          * it works more like DVCS which many developers are familiar with
          * the detailed history of the development process is preserved
          
          And the downsides:
          
          * each checkpoint would require a commit message at the creation of the checkpoint
          * more complex to write since there will be pressure from users to be able to
          manipulate the checkpoints, edit the commit messages, merge checkpoints, etc
          before the commit to the server is performed.
          
          
          

          Show
          ari Ari Maniatis added a comment - I do hope this feature makes it into 1.8 since it would be extremely useful (alongside the shelving idea which is closely related to this concept). I agree that it is essential this idea work completely offline. Also, has thought been given about whether a series of checkpoints result in a series of commits or just one commit. Pros to creating multiple commits: * it works more like DVCS which many developers are familiar with * the detailed history of the development process is preserved And the downsides: * each checkpoint would require a commit message at the creation of the checkpoint * more complex to write since there will be pressure from users to be able to manipulate the checkpoints, edit the commit messages, merge checkpoints, etc before the commit to the server is performed.
          Hide
          subversion-importer Subversion Importer added a comment -

          From the IRC svn-dev chat:
          
          [12:11] <gbb> idea:  [c/sh]ould merge automagically take a security diff before
          merging, just to protect the clumsy from their foolish mistakes?  (I merged my
          working copy instead of my test dir in gdb, oww, repairable but ugh...)
          [12:12] <stsp> gbb, you mean something like merge --dry-run?
          [12:13] <stsp> with such things, it's tricky: if we do a check by default, one
          set of people will complain about the additional overhead, while the other group
          will complain about the need to specify an option to get the safe behaviour
          [12:13] <gbb> hrm dry-run would have helped but not protected me from merging
          over all my work.  ;(  (luckily my emacs is my handbag and most of those files
          were still open)
          [12:14] <stsp> i think it's the type of mistake that you just need to learn to
          avoid over time
          [12:15] <stsp> if we had checkpoints implemented, you could checkpoint your
          working copy before a merge, to keep a record of the pre-merge state
          [12:15] <stsp> i think that would be a nice solution
          [12:16] <stsp> merge could automatically create such a checkpoint, in fact!
          

          Original comment by gbg

          Show
          subversion-importer Subversion Importer added a comment - From the IRC svn-dev chat: [12:11] <gbb> idea: [c/sh]ould merge automagically take a security diff before merging, just to protect the clumsy from their foolish mistakes? (I merged my working copy instead of my test dir in gdb, oww, repairable but ugh...) [12:12] <stsp> gbb, you mean something like merge --dry-run? [12:13] <stsp> with such things, it's tricky: if we do a check by default, one set of people will complain about the additional overhead, while the other group will complain about the need to specify an option to get the safe behaviour [12:13] <gbb> hrm dry-run would have helped but not protected me from merging over all my work. ;( (luckily my emacs is my handbag and most of those files were still open) [12:14] <stsp> i think it's the type of mistake that you just need to learn to avoid over time [12:15] <stsp> if we had checkpoints implemented, you could checkpoint your working copy before a merge, to keep a record of the pre-merge state [12:15] <stsp> i think that would be a nice solution [12:16] <stsp> merge could automatically create such a checkpoint, in fact! Original comment by gbg
          Hide
          julianfoad Julian Foad added a comment - - edited

          I am working on Shelving and Checkpointing.

          Show
          julianfoad Julian Foad added a comment - - edited I am working on Shelving and Checkpointing. discussing in dev@ threads, initially " [RFC] Shelving and Checkpointing " designing in the document " Shelving-Checkpointing Dev " prototyping in the " shelve-checkpoint " & " shelve-checkpoint3 " branches
          Hide
          julianfoad Julian Foad added a comment -

          I am implementing the proposal in dev@ thread "Checkpointing v1 design"

          Show
          julianfoad Julian Foad added a comment - I am implementing the proposal in dev@ thread " Checkpointing v1 design "

            People

            • Assignee:
              julianfoad Julian Foad
              Reporter:
              cmpilato C. Michael Pilato
            • Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development