subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ari Maniatis (JIRA)" <>
Subject [jira] [Commented] (SVN-3625) Commit shelving
Date Thu, 17 Nov 2016 02:14:58 GMT


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

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:
>             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

View raw message