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!

(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".

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.

Blair Zajac
added a comment - 05/May/10 20:12 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.

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.

Subversion Importer
added a comment - 29/Jul/10 21:39 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

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.

Greg Stein
added a comment - 29/Jul/10 22:42 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.

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?

Subversion Importer
added a comment - 29/Dec/10 00:57 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

Subversion Importer
added a comment - 29/Dec/10 01:01 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

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.

Greg Stein
added a comment - 29/Dec/10 11:33 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.

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.

Subversion Importer
added a comment - 14/Sep/12 12:00 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

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

Stefan Sperling
added a comment - 14/Sep/12 14:27 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

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.

Subversion Importer
added a comment - 16/Sep/12 20:17 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

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.

Mike Evans
added a comment - 16/Nov/16 16:26 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.

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.

Ari Maniatis
added a comment - 17/Nov/16 02:14 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.

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.

Alonzo Lofaro
added a comment - 05/Dec/17 16:28 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.