[
https://issues.apache.org/jira/browse/SVN-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971262#comment-16971262
]
Rio Velarde commented on SVN-3625:
----------------------------------
Something seems to be wrong with how this is set up (at least for me), beyond
the expected performance limitations over the older versions. On the latest
version of TortoiseSVN, I attempt to shelve nine cs files (a combined size of
~300 KB) and it processes for ten minutes until saying it has transferred up to
8 GB of data and then fails with the following error: "Subversion reported an
error: No path was shelved"
Ignoring the error, even if it worked after ten minutes I can't imagine why it
would need to transfer 8 whole GB just to back up 300 KB and it is so
unfeasible that I just have to use patching instead. I am coming from a
Perforce background where a shelve, which is a server-side one, always takes a
couple seconds on code files.
I know you've said the new features require the longer processing time, but
surely it's not worth having them in when it seems to have such significant
issues?
> Commit shelving
> ---------------
>
> Key: SVN-3625
> URL: https://issues.apache.org/jira/browse/SVN-3625
> Project: Subversion
> Issue Type: Improvement
> Components: libsvn_client
> Affects Versions: trunk
> Reporter: C. Michael Pilato
> Assignee: Julian Foad
> Priority: Major
> Labels: api, needsdesign
> Fix For: unscheduled, 1.12.0
>
>
> (i) See the wiki pages: [Shelving and
> Checkpointing|https://cwiki.apache.org/confluence/display/SVN/Shelving+and+Checkpointing]
> 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 'svn patch' to recreate local primary
> task mods; deal with all the stuff (copies and moves, directories, etc.) that
> 'patch' can't represent; resume primary task.
> 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
(v8.3.4#803005)
