[ 
https://issues.apache.org/jira/browse/SVN-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Foad updated SVN-3625:
-----------------------------
    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".


  was:
{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}


> 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
>            Assignee: Julian Foad
>              Labels: api, needsdesign
>             Fix For: 1.10-consider
>
>
> 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".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to