[
https://issues.apache.org/jira/browse/SVN-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15672418#comment-15672418
]
Ari Maniatis commented on SVN-3625:
-----------------------------------
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.
> 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)
