Details

      Description

      Developers often need to temporarily put aside in-process working copy changes to begin some other usually-short-lived task. You know the routine. You're halfway through the implementation of a medium-sized feature when – stop the presses! A customer just found a mission-critical bug in the app!

      Current workarounds include:

      • create a branch; switch to branch; commit unfinished primary task code to branch; switch back; handle and commit secondary task; merge from branch; resume primary task.
      • use 'svn diff' to make a patchfile for primary task work; svn revert -R; handle and commit secondary task; use 'patch' to recreate local primary task mods; deal with all the stuff (prop changes, added/deleted files, etc.) that 'patch' can't represent; resume primary task.
      • (same as above, except that in 1.7 you can use 'svn patch' instead of 'patch' and the fixup step)

      A better approach that avoids the need to create server branches and to marshal/unmarshal changes away from Subversion would be to support 'svn shelve/unshelve' commands, where "shelve" means "squirrel away my changes into the working copy metadata and revert them from the WORKING tree " and "unshelve" means "merge the changes I previously squirreled away back into my WORKING tree".

        Issue Links

          Activity

          Hide
          cmpilato C. Michael Pilato added a comment -

          To be clear, this is a single-depth stack of WC metadata and content.
          

          Show
          cmpilato C. Michael Pilato added a comment - To be clear, this is a single-depth stack of WC metadata and content.
          Hide
          blair Blair Zajac added a comment -

          Not that this is the best place to have a discussion on this
          feature, but I would be in favor of extending it to having a
          arbitrary depth stack of patches that you could you could pop,
          push and reorder, much like stacked git or hg's mq's extension.
          
          

          Show
          blair Blair Zajac added a comment - Not that this is the best place to have a discussion on this feature, but I would be in favor of extending it to having a arbitrary depth stack of patches that you could you could pop, push and reorder, much like stacked git or hg's mq's extension.
          Hide
          subversion-importer Subversion Importer added a comment -

          I think both this issue and the related 3626 "checkpointing" 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 3626 "checkpointing" 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
          gstein Greg Stein added a comment -

          Storing it on the server completely ignores the design intents: offline work, fast, and partial/not-ready-
          to-commit.
          
          If you are online and want to store it on the server, then just commit it to a new branch.
          
          

          Show
          gstein Greg Stein added a comment - Storing it on the server completely ignores the design intents: offline work, fast, and partial/not-ready- to-commit. If you are online and want to store it on the server, then just commit it to a new branch.
          Hide
          subversion-importer Subversion Importer added a comment -

          One other rather obvious workaround that was missed: Check out a new working
          copy and do your temporary work there.
          
          I can't see what benefit the proposed 'shelving' feature has over the above
          solution to this problem, but given that it is so obvious I suspect there might
          be something I've missed.  Can someone enlighten me?
          

          Original comment by happydog

          Show
          subversion-importer Subversion Importer added a comment - One other rather obvious workaround that was missed: Check out a new working copy and do your temporary work there. I can't see what benefit the proposed 'shelving' feature has over the above solution to this problem, but given that it is so obvious I suspect there might be something I've missed. Can someone enlighten me? Original comment by happydog
          Hide
          subversion-importer Subversion Importer added a comment -

          OK - just realised that you can't do a fresh check-out if offline.
          
          However, you can make a copy of your original working copy directory and do a
          revert on that, and you'll end up in the same place.
          

          Original comment by happydog

          Show
          subversion-importer Subversion Importer added a comment - OK - just realised that you can't do a fresh check-out if offline. However, you can make a copy of your original working copy directory and do a revert on that, and you'll end up in the same place. Original comment by happydog
          Hide
          gstein Greg Stein added a comment -

          Checking out a new working copy, or doing a local-copy can (relatively-speaking) take a LONG time. If 
          your working copy is several gigabytes, or maybe tens-of-thousands of files/dirs, then establishing a 
          new working copy isn't a lot of fun.
          
          We could optimize the checkout of a new working copy, but are still bound to the local filesystem's I/O 
          constraints. On most platforms, this would be pretty time consuming, no matter what we do at the 
          application level to optimize it.
          
          The "shelve" concept proposes to revert the (say) three files that have changed, preserving those 
          changes into a private area for later restoration. Dealing with three files, rather than three *thousand* is 
          always a win. And conceptually,  you don't have to manage/deal with a new working copy. And your 
          *build* constructions/dependencies are mostly the same, so the build/test cycle is fast (compared to a 
          fresh build from a fresh checkout).
          
          In short, the "shelve" idea is a simple way to un-modify some locally changed files and then progress on 
          another change. There may be cases where a fresh checkout can be "more optimal", but I believe it is 
          easier overall (from a mental/build/checkout/update standpoint) to simply undo the local changes to 
          make the working copy available for new changes. And after that process, to restore those local 
          changes.
          
          

          Show
          gstein Greg Stein added a comment - Checking out a new working copy, or doing a local-copy can (relatively-speaking) take a LONG time. If your working copy is several gigabytes, or maybe tens-of-thousands of files/dirs, then establishing a new working copy isn't a lot of fun. We could optimize the checkout of a new working copy, but are still bound to the local filesystem's I/O constraints. On most platforms, this would be pretty time consuming, no matter what we do at the application level to optimize it. The "shelve" concept proposes to revert the (say) three files that have changed, preserving those changes into a private area for later restoration. Dealing with three files, rather than three *thousand* is always a win. And conceptually, you don't have to manage/deal with a new working copy. And your *build* constructions/dependencies are mostly the same, so the build/test cycle is fast (compared to a fresh build from a fresh checkout). In short, the "shelve" idea is a simple way to un-modify some locally changed files and then progress on another change. There may be cases where a fresh checkout can be "more optimal", but I believe it is easier overall (from a mental/build/checkout/update standpoint) to simply undo the local changes to make the working copy available for new changes. And after that process, to restore those local changes.
          Hide
          subversion-importer Subversion Importer added a comment -

          Hi, 
          Not sure what is the status for shelving for Subversion.  
          I think looking at the post from users are confused between Check-pointing and
          Shelving, they are two different features. 
          As far as I understand is,  shelving a copy should be made on the repo(a
          parallel copy to actual trunk (let not get confused with branch)only changes are
          shelved) as mentioned by Shawn  which could be unshelved by another user. 
          This is quite useful feature for code review when  bug are found after CF and
          require approval from peer so the approver can get the shelve copy to verify
          once done the user can unshelve and submit to repo.
          
          Check-pointing is done offline and is only restrictive to the current client so
          he/she can check his/her committed locally similar to  DVCS commit. 
          
          

          Original comment by rohanb

          Show
          subversion-importer Subversion Importer added a comment - Hi, Not sure what is the status for shelving for Subversion. I think looking at the post from users are confused between Check-pointing and Shelving, they are two different features. As far as I understand is, shelving a copy should be made on the repo(a parallel copy to actual trunk (let not get confused with branch)only changes are shelved) as mentioned by Shawn which could be unshelved by another user. This is quite useful feature for code review when bug are found after CF and require approval from peer so the approver can get the shelve copy to verify once done the user can unshelve and submit to repo. Check-pointing is done offline and is only restrictive to the current client so he/she can check his/her committed locally similar to DVCS commit. Original comment by rohanb
          Hide
          stsp Stefan Sperling added a comment -

          Hi Rohan,
          the current status is that nobody is working on these features yet.
          
          Shelving as suggested by gstein is also supposed to be an offline operation.
          Shelving changes in the repository is already possible today by copying a
          working copy into the repository, e.g. like this: cd working-copy; svn copy .
          ^/shelves/myshelve
          

          Show
          stsp Stefan Sperling added a comment - Hi Rohan, the current status is that nobody is working on these features yet. Shelving as suggested by gstein is also supposed to be an offline operation. Shelving changes in the repository is already possible today by copying a working copy into the repository, e.g. like this: cd working-copy; svn copy . ^/shelves/myshelve
          Hide
          subversion-importer Subversion Importer added a comment -

          I think it would be great if a repository were maintained hidden into the working copy for commit 
          shelving (i.e. ci --shelve), so that svn infrastructure is used to enhance svn one step futher. When 
          you shelve your changes they are commited to the internal local repository. You can revert your 
          working copy to any shelve revision. It would be still centralized by design, but you could manage 
          commits more meaningfully. 
          

          Original comment by emelor

          Show
          subversion-importer Subversion Importer added a comment - I think it would be great if a repository were maintained hidden into the working copy for commit shelving (i.e. ci --shelve), so that svn infrastructure is used to enhance svn one step futher. When you shelve your changes they are commited to the internal local repository. You can revert your working copy to any shelve revision. It would be still centralized by design, but you could manage commits more meaningfully. Original comment by emelor
          Hide
          vacao Mike Evans added a comment -

          In moving from hg to svn, this is the feature that I most miss. It is crucial in promoting smaller, single-purposed commits and good code structure. For example, it allows you see some smaller refactoring that should be done to make the feature you are working on cleaner, put your unfinished feature aside, refactor and test your code cleanly, commit, and then resume building your feature.

          I'm frustrated with those who have suggested storing your shelved code to the (remote) repository, as I think it muddies the waters and makes the feature seem harder. If you want to share your code or make sure its preserved, a branch is a great place for that. Shelving is supposed to be lighter and faster, for code that is not ready for anyone else to see.

          I have seen shelve implementations without it, but I think shelving is greatly enhanced by each shelf having a name. This allows you to put off several unfinished efforts, and then select which one you want to pick back up. I don't see a stack-like implementation as being as useful, since I may not want to resume work on the last shelf I worked on, even though I do not wart to discard it.

          Show
          vacao Mike Evans added a comment - In moving from hg to svn, this is the feature that I most miss. It is crucial in promoting smaller, single-purposed commits and good code structure. For example, it allows you see some smaller refactoring that should be done to make the feature you are working on cleaner, put your unfinished feature aside, refactor and test your code cleanly, commit, and then resume building your feature. I'm frustrated with those who have suggested storing your shelved code to the (remote) repository, as I think it muddies the waters and makes the feature seem harder. If you want to share your code or make sure its preserved, a branch is a great place for that. Shelving is supposed to be lighter and faster, for code that is not ready for anyone else to see. I have seen shelve implementations without it, but I think shelving is greatly enhanced by each shelf having a name. This allows you to put off several unfinished efforts, and then select which one you want to pick back up. I don't see a stack-like implementation as being as useful, since I may not want to resume work on the last shelf I worked on, even though I do not wart to discard it.
          Hide
          ari Ari Maniatis added a comment -

          Checkpointing (SVN-3626) and shelving are really almost the same idea. Both are offline (we don't need server-side solutions since we already have the ability to create branches/tags as needed) ways to store changesets.

          Shelving would typically include immediately reverting all changes after the changeset is stored. Checkpointing would not.

          My personal opinion is that the future of subversion depends on these features. git has obliterated the use of svn in very many situations, mainly because of its offline capabilities and superior merging. Now while svn merging and change tracking has improved a lot, it is still purely online.

          The primary benefit for my workflow is that offline checkpointing and shelving makes it easier for developers to:

          • commit often with easily readable changesets and commit messages, even when they aren't ready to expose those changes to the rest of the team
          • switch between working on different issues without needing to keep patch files or multiple working copies

          Unfortunately I'm not a C developer, so I can only wave from the sidelines and hope that some subversion developer with the skills also has the same needs.

          Show
          ari Ari Maniatis added a comment - Checkpointing ( SVN-3626 ) and shelving are really almost the same idea. Both are offline (we don't need server-side solutions since we already have the ability to create branches/tags as needed) ways to store changesets. Shelving would typically include immediately reverting all changes after the changeset is stored. Checkpointing would not. My personal opinion is that the future of subversion depends on these features. git has obliterated the use of svn in very many situations, mainly because of its offline capabilities and superior merging. Now while svn merging and change tracking has improved a lot, it is still purely online. The primary benefit for my workflow is that offline checkpointing and shelving makes it easier for developers to: commit often with easily readable changesets and commit messages, even when they aren't ready to expose those changes to the rest of the team switch between working on different issues without needing to keep patch files or multiple working copies Unfortunately I'm not a C developer, so I can only wave from the sidelines and hope that some subversion developer with the skills also has the same needs.
          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 " branch
          Hide
          julianfoad Julian Foad added a comment -

          TortoiseSVN now has an initial implementation of "Shelve" and "Unshelve" commands, on the TortoiseSVN "shelve" branch.

          Show
          julianfoad Julian Foad added a comment - TortoiseSVN now has an initial implementation of "Shelve" and "Unshelve" commands, on the TortoiseSVN "shelve" branch .
          Hide
          alonzolofaro Alonzo Lofaro added a comment -

          It's very good news that subversion is getting this feature.

          Working with patches is very error prone when you get patch-rejects. I just find patch rejects unusable so for me I would avoid rejects. I would want shelving to be applied using 3-way merge as I often find my changes conflict with other people's when I am trying to apply a patch.

          Show
          alonzolofaro Alonzo Lofaro added a comment - It's very good news that subversion is getting this feature. Working with patches is very error prone when you get patch-rejects. I just find patch rejects unusable so for me I would avoid rejects. I would want shelving to be applied using 3-way merge as I often find my changes conflict with other people's when I am trying to apply a patch.

            People

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

              Dates

              • Created:
                Updated:

                Development