Bug 126344 - Ability to "Shelve Changes"
Ability to "Shelve Changes"
Status: RESOLVED FIXED
Product: versioncontrol
Classification: Unclassified
Component: Code
6.x
All All
: P1 (vote)
: 7.1
Assigned To: issues@versioncontrol
issues@versioncontrol
: PLAN
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-31 00:06 UTC by _ tboudreau
Modified: 2011-08-04 13:49 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2008-01-31 00:06:50 UTC
A very interesting IntelliJ feature which got a lot of attention from the audience at an IDE shootout I recently participated in was a feature called "Shelve 
Changes" in its version control integration.  

Use case:  Say you have a modified file you are working on.  Suddenly you get a P1 bug that also requires you to make changes in that file, but the changes 
are unrelated to the changes you already have locally, or your changes are unfinished.  You can "shelve" the changes, and a diff is stored, and the file is 
reverted.  You fix the P1 bug, commit it, and then "unshelve" your changes.

The IDE remembers that you have shelved changes for this file, and there is a UI that shows all the ones on your "shelf", and you an reapply them with a right 
click and an action.
Comment 1 John Rice 2008-01-31 00:39:53 UTC
Wouldn't you just clone your  working_clone that has the uncommitted file changes to say p1_clone, work on this p1_clone
make your fix, push back the changes and then go back to your working_clone?

In your p1_clone you can do a Show History for the last few days and revert any of the committed changes before starting
your work if you need to.
Comment 2 _ tboudreau 2008-01-31 00:57:27 UTC
I would do that if I were using Mercurial, yes :-)  It's one of the reasons I like Mercurial.

But for CVS or SVN, it's more difficult.  I would need either a fresh checkout, or I would have to 
1. make a patch file
2. revert my local changes
3. fix my P1
4. commit that, and then 
5. reapply my patch

This feature collapses 1 and 2 into one easy step, and 5 into another easy step.  Much simpler to click twice than to export a patch, revert, and reapply 
when I'm done.
Comment 3 Maros Sandor 2008-01-31 11:00:53 UTC
We planned to do similar feature for 6.0 Local History but unfortunately we did not come to UI conclusion with HIE on
this. What we thought of:

1) Have a Set Label... in Local History that would label the current state of files on disk
2) Have a Rollback to Label... in Local History that would revert changes to the previously labeled state
3) As a bonus, have a Set Base Label... that would behave similarily to real versioning Base so that Inline Diff, Diff,
Rollback and other base-related versioning operations would work also with just Local History

I assume this would cover your use cases:

1) Set Label -> Work_before_Fix
2) Rollback Changes (in whatever versioning system)
3) Do your fixing
4) Rollback To Label -> Work_before_Fix
Comment 4 _ tboudreau 2008-01-31 16:45:54 UTC
Cool.  I would say, use the same term as IJ did - "shelve changes" requires much less thought to understand than "set label".
Comment 5 Ondrej Vrabec 2011-08-03 11:50:34 UTC
fixed: Team -> Shelve Changes and Team -> Unshelve Changes
Works for subversion and mercurial.
Comment 6 Quality Engineering 2011-08-04 13:49:29 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/c2bfbe83e9ba
User: Ondrej Vrabec <ovrabec@netbeans.org>
Log: Issue #126344 - Ability to "Shelve Changes"
general infrastructure


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo