subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Evans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SVN-3625) Commit shelving
Date Wed, 16 Nov 2016 16:26:58 GMT

    [ 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)

Mime
View raw message