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.

        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

          People

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

            Dates

            • Created:
              Updated:

              Development