Merge lp:~abentley/bzr/branch-store into lp:bzr
| Status: | Merged |
|---|---|
| Merged at revision: | 6540 |
| Proposed branch: | lp:~abentley/bzr/branch-store |
| Merge into: | lp:bzr |
| Diff against target: |
847 lines (+496/-35) 16 files modified
bzrlib/branch.py (+57/-0) bzrlib/builtins.py (+6/-2) bzrlib/errors.py (+21/-0) bzrlib/lock.py (+8/-0) bzrlib/remote.py (+8/-0) bzrlib/shelf.py (+23/-9) bzrlib/switch.py (+30/-11) bzrlib/tests/blackbox/test_switch.py (+38/-1) bzrlib/tests/per_branch/test_branch.py (+89/-0) bzrlib/tests/test_switch.py (+58/-10) bzrlib/tests/test_workingtree.py (+32/-1) bzrlib/workingtree.py (+29/-0) doc/en/release-notes/bzr-2.6.txt (+2/-1) doc/en/user-guide/index-plain.txt (+1/-0) doc/en/user-guide/index.txt (+1/-0) doc/en/user-guide/switch_store.txt (+93/-0) |
| To merge this branch: | bzr merge lp:~abentley/bzr/branch-store |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Martin Packman (community) | Approve on 2012-07-23 | ||
| Jelmer Vernooij (community) | 2012-07-18 | Approve on 2012-07-20 | |
|
Review via email:
|
|||
Commit Message
(abentley) Switch stores uncommitted changes in branch (Aaron Bentley)
Description of the Change
This branch adds one of my favourite pipeline features to core Bazaar: storing and restoring uncommitted changes when switching between branches.
With colocated workflows now supported by core Bazaar, we should make them work smoothly. Storing uncommitted changes makes it convenient to switch between branches as needed.
The effect is similar to using "shelve --all" and "unshelve", but since the changes are associated with the branch instead of the working tree, bzr is able to select the correct changes automatically during the switch operation.
I have made this new mode the default because I believe it is the common case, and the least-likely to cause problems for users. Specifically, merging changes into existing branches often leads to conflicts. So for users who do not intend to apply the changes from their current branch to the new branch, there are two problems: 1. the changes are applied to the new branch, 2. The changes acquire conflicts, which makes it difficult to restore them to the original branch. By contrast, the only case where the new behaviour leads to conflicts is when the new branch has stored uncommitted changes, and the new branch's last_revision has changed since. This is possible, but not common.
There are two classes of users who may be surprised when switch merges their uncommitted changes into the new branch: users unfamiliar with switch, and users who did not realize they had uncommitted changes in their tree.
| Jelmer Vernooij (jelmer) wrote : | # |
| Aaron Bentley (abentley) wrote : | # |
> On Wed, Jul 18, 2012 at 08:47:19PM -0000, Aaron Bentley wrote:
> Personally, I prefer the current behaviour; it means it's possible to
> switch over to a new branch easily if you happen to change a few
> things that really deserve their own branch ("bzr switch -b foo && bzr
> ci").
I'm willing to leave the current behaviour as the default. I think this behaviour is safer and more convenient in most cases. Please try it out for a few weeks, and I think you'll find you want it as the default, too.
> The current behaviour is also consistent with git, for what
> that is worth.
Okay. I was under the impression git didn't automatically merge, but said "error: You have local changes to "X"; cannot switch branches." like this: http://
In fact, one of my co-workers who uses git was surprised that bzr didn't behave like the above, and that was one of the reasons I worked on this.
> If switch is going to rely on them, then the new methods on Branch
> should really be public. Foreign branch support will break with this
> merge proposal as-is.
Per our IRC discussion, I'll turn get_unshelver/
| Aaron Bentley (abentley) wrote : | # |
Further research suggests git only errors if the uncommitted changes *conflict*: http://
| Aaron Bentley (abentley) wrote : | # |
Updated per our discussion. I've removed _get/_put_
| Jelmer Vernooij (jelmer) wrote : | # |
Thanks; this looks good to land to me now. It would be good if somebody else (mgz?) could also have a quick look at it.
Would --store perhaps be better named as --shelve, since that's a term people are already familiar with?
| Aaron Bentley (abentley) wrote : | # |
> Would --store perhaps be better named as --shelve, since that's a term people
> are already familiar with?
I thought it would be confusing to use "shelf", because of the UI differences between these and shelves:
- they cannot be manipulated with "bzr shelve/unshelve"
- they don't have the same interactive UI as "bzr shelve"
- there is one store per branch, but many shelves per working tree
What do you think?
Aaron
| Jelmer Vernooij (jelmer) wrote : | # |
> > Would --store perhaps be better named as --shelve, since that's a term
> people
> > are already familiar with?
>
> I thought it would be confusing to use "shelf", because of the UI differences
> between these and shelves:
>
> - they cannot be manipulated with "bzr shelve/unshelve"
> - they don't have the same interactive UI as "bzr shelve"
> - there is one store per branch, but many shelves per working tree
>
> What do you think?
Hmm, I hadn't considered it that way - I guess it could indeed be confusing if looks like a shelve but isn't quite a shelve. Let me retract that suggestion.
| Martin Packman (gz) wrote : | # |
Code all looks good, tests are helpful in explaining the intended behaviour.
Documentation is rather on the light side, a help string for a command switch and an entry in what's new isn't going to be enough for people who want this to find it.
Using --store to mean both stash the changes to the current branch and unstash the changes to the target branch is a slight stretch of english.
I'd like to see a blackbox test where both branches have stored changes.
Overall, this seems more like an alternative behaviour for switch that some people might want to configure on all the time, rather than a command line switch for situational use.
How would it work if say, you accidentally switched back to a branch with stored changes without passing --store, then commited something, then wanted to get your pending work again? Shelves are hard to recover manually, we don't want to introduce a new workflow that's likely to confuse people.
Configuring stuff off by default can be a bad compromise, we already have a bunch of good changes stuck behind an obscure option or command due to disagreements or not being finished.
Apart from question of whether this should really be a switch param rather than a config option, don't think anything should block this landing for now though.
- 6570. By Aaron Bentley on 2012-07-23
-
Add docs on switch --store.
- 6571. By Aaron Bentley on 2012-07-23
-
Tweak docs.
- 6572. By Aaron Bentley on 2012-07-23
-
Update blackbox test to show storing and restoring in one switch.
| Aaron Bentley (abentley) wrote : | # |
> Documentation is rather on the light side, a help string for a command switch
> and an entry in what's new isn't going to be enough for people who want this
> to find it.
I've added switch_store.txt
> Using --store to mean both stash the changes to the current branch and unstash
> the changes to the target branch is a slight stretch of english.
Yes, but I can't think of anything better. It's also a bit of a cheat in that "store" and "restore" aren't really antonyms.
> I'd like to see a blackbox test where both branches have stored changes.
Per our IRC discussion, I've changed test_store_
> Overall, this seems more like an alternative behaviour for switch that some
> people might want to configure on all the time, rather than a command line
> switch for situational use.
Everyone will want the current default behaviour sometimes. If they alias "switch=switch --store", they can get it back with "switch --no-store". With a config option, it would be much more painful.
> How would it work if say, you accidentally switched back to a branch with
> stored changes without passing --store, then commited something, then wanted
> to get your pending work again?
You would use "bzr switch . --store" to get it back. I've added it to the docs.
> Configuring stuff off by default can be a bad compromise, we already have a
> bunch of good changes stuck behind an obscure option or command due to
> disagreements or not being finished.
Hopefully, we can revisit the default in the future. For now, this gets me an approval from jelmer.
Aaron

On Wed, Jul 18, 2012 at 08:47:19PM -0000, Aaron Bentley wrote:
> This branch adds one of my favourite pipeline features to core
> Bazaar: storing and restoring uncommitted changes when switching
> between branches.
> With colocated workflows now supported by core Bazaar, we should
> make them work smoothly. Storing uncommitted changes makes it
> convenient to switch between branches as needed.
> The effect is similar to using "shelve --all" and "unshelve", but
> since the changes are associated with the branch instead of the
> working tree, bzr is able to select the correct changes
> automatically during the switch operation.
> I have made this new mode the default because I believe it is the
> common case, and the least-likely to cause problems for users.
> Specifically, merging changes into existing branches often leads to
> conflicts. So for users who do not intend to apply the changes from
> their current branch to the new branch, there are two problems: 1.
> the changes are applied to the new branch, 2. The changes acquire
> conflicts, which makes it difficult to restore them to the original
> branch. By contrast, the only case where the new behaviour leads to
> conflicts is when the new branch has stored uncommitted changes, and
> the new branch's last_revision has changed since. This is possible,
> but not common.
> There are two classes of users who may be surprised when switch
> merges their uncommitted changes into the new branch: users
> unfamiliar with switch, and users who did not realize they had
> uncommitted changes in their tree.
Personally, I prefer the current behaviour; it means it's possible to
switch over to a new branch easily if you happen to change a few
things that really deserve their own branch ("bzr switch -b foo && bzr
ci"). The current behaviour is also consistent with git, for what
that is worth.
If switch is going to rely on them, then the new methods on Branch
should really be public. Foreign branch support will break with this
merge proposal as-is.
Cheers,
Jelmer