bzr should have one shelf per branch.

Bug #731729 reported by Stavros Korokithakis
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

I would like to accommodate the following workflow:

I work on branch feature1.
Half way through, I decide to switch to colocated branch feature2.
My current uncommitted changes are shelved, and I switch to feature2.
I work on feature2, and half-way through I decide to finish working on feature1.
I switch to feature1, feature2's uncommitted changes are shelved and feature1's previous changes are unshelved.
I work on feature1, finish and commit.
I switch to feature2, the uncommitted changes are unshelved into my working directory.

Basically, something like automatic shelving/unshelving when switching, or one shelf per branch.

Revision history for this message
Martin Pool (mbp) wrote :

Interesting ideas.

I think in some cases it is useful to be able to unshelve from one branch into another, and also to be able to carry across uncommitted changes. But we could certainly usefully add options to do the opposite, and perhaps consider whether they should be the default.

tags: added: colocated-branches shelf switch
Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium
tags: added: feature ui
Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 731729] Re: bzr should have one shelf per branch.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/14/2011 9:42 AM, Martin Pool wrote:
> Interesting ideas.
>
> I think in some cases it is useful to be able to unshelve from one
> branch into another, and also to be able to carry across uncommitted
> changes. But we could certainly usefully add options to do the
> opposite, and perhaps consider whether they should be the default.
>
> ** Tags added: colocated-branches shelf switch
>
> ** Changed in: bzr
> Status: New => Confirmed
>
> ** Changed in: bzr
> Importance: Undecided => Medium
>
> ** Tags added: feature ui
>

Note that bzr-pipeline does some sort of magic to have per-branch
shelves. Such that using the pipe-switch (not sure of the name) command,
will shelve, switch branches and switch working shelves.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk199wMACgkQJdeBCYSNAAMaFwCcCKQgilWrEf6ajbWIib7BRcT7
Wk0AoNSVLDaK7W5U4d0UmDPqztVzxsni
=eYZs
-----END PGP SIGNATURE-----

Revision history for this message
Stavros Korokithakis (stavrosk) wrote :

bzr-pipeline does what I describe, but I find the piping workflow not to be a good fit for what I'm doing. Basically, the colo plugin shelving all changes when switching branches would be *ideal*. That would enable me to just switch between feature branches at will, regardless of whether the feature is done or not. It would make my workflow *much* more efficient.

Porting changes from other branches would be as simple as "bzr switch colo:other-branch --no-shelve" or something equivalent...

Revision history for this message
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/14/2011 1:01 PM, Stavros Korokithakis wrote:
> bzr-pipeline does what I describe, but I find the piping workflow not to
> be a good fit for what I'm doing. Basically, the colo plugin shelving
> all changes when switching branches would be *ideal*. That would enable
> me to just switch between feature branches at will, regardless of
> whether the feature is done or not. It would make my workflow *much*
> more efficient.
>
> Porting changes from other branches would be as simple as "bzr switch
> colo:other-branch --no-shelve" or something equivalent...
>

Out of curiosity, if you are using colo-branches for feature
development, why do you need to keep shelves around. why not just commit
the work and switch?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1+BtkACgkQJdeBCYSNAAObDQCcDc3G9UU/w3kVKZCAkbcYi0Hh
FjEAoNd+AoRrH4dISB9fHAIhSpDp7vBj
=LsDG
-----END PGP SIGNATURE-----

Revision history for this message
Stavros Korokithakis (stavrosk) wrote :

I'm too averse to committing half-working releases, I like to be able to restore to each commit and have things work reasonably well. I realise that this is a personal preference, and that I can commit and then uncommit, but these feel much less clean than the way bzr-pipeline does it (I believe
 git does it that way as well?)...

Revision history for this message
Martin Pool (mbp) wrote :

On 14 March 2011 23:26, Stavros Korokithakis <email address hidden> wrote:
> I'm too averse to committing half-working releases, I like to be able to restore to each commit and have things work reasonably well. I realise that this is a personal preference, and that I can commit and then uncommit, but these feel much less clean than the way bzr-pipeline does it (I believe
>  git does it that way as well?)...

I believe git does also encourage you to commit before switching to
save half done work. I don't really like that either. At least an
option to save uncommitted work outside of the tree would be
worthwhile.

Revision history for this message
Gordon Tyler (doxxx) wrote :

I have the same "quirk" as Stavros. I dislike committing partial work on feature branches, especially if it doesn't even compile. Primarily because I use the diff of uncommitted changes to remind me what I've changed and where I am in my current work. I've been shelving and unshelving manually like he describes so something to make it automatic like he suggests would be quite useful to me.

Revision history for this message
Stavros Korokithakis (stavrosk) wrote :

Is there any update on this? Maybe some feature that has been developed makes this possible now, via a hook or something similar?

Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.