[
https://issues.apache.org/jira/browse/SVN-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15670897#comment-15670897
]
Mike Evans commented on SVN-3625:
---------------------------------
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.
> Commit shelving
> ---------------
>
> Key: SVN-3625
> URL: https://issues.apache.org/jira/browse/SVN-3625
> Project: Subversion
> Issue Type: New Feature
> Components: libsvn_client
> Affects Versions: trunk
> Reporter: C. Michael Pilato
> Labels: api, needsdesign
> Fix For: 1.10-consider
>
>
> {noformat:nopanel=true}
> 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".
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
