[
https://issues.apache.org/jira/browse/SVN-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16971262#comment-16971262
]
Rio Velarde edited comment on SVN-3625 at 11/11/19 4:40 AM:
------------------------------------------------------------
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"
After inspecing the generated files in the experimental folder, it looks like
it had started shelving the entire repo in there. Perhaps this is just an issue
with the Tortoise GUI not implementing the command correctly though?
I know you've said the new features require the longer processing time, but
even if it were working properly with Tortoise and down to the expected couple
minutes, I'd rather have less features and have it be instant.
was (Author: eagleheart):
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)
