Re: Workflow to accumulate individual changes?

[Óscar Fuentes]

Juanma Barranquero <address@hidden> writes:

> On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <address@hidden> wrote:
>
>> I don't understand what you're concerned about (yes, I've seen the
>> followup which includes the footnote).
>
> Well, if you read the note, you know what am I concerned about: not
> the time for checking out the files, but the time to get the branch in
> a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
> while "make bootstrap" is ~20min. The only fix for that is creating a
> script to copy .o, .elc and other generated files from another branch.
> Quite a fuss just to commit (and store for the future) a one-liner;
> that's why I think of having a branch for these micro-issues. (Well,
> colocated branches à la git would be wonderful for this case...)

https://launchpad.net/bzr-loom

It is underdocumented, but it works AFAIK. You can search the internet
for experiences with it.

OTOH, some people emulate colocated branches with `bzr switch'. The idea
is that you have a checkout for hacking that you bind to wathever branch
you chose to work on. For example, lets suppose that you created your
working checkout with:

bzr co trunk my-playground   # you need to do this only once

from now on, when you need a small feature, you create a branch for it:

bzr branch --no-tree trunk fix-foo

this is a very fast and inexpensive operation on a shared repository, as
it doesn't even require to create the working tree.

Now, if you want to work on `fix-foo', from `my-playground' you do

bzr switch ../fix-foo

you do something and, eventually

bzr commit -m "done!"

this will update `fix-foo'. Later, you can proced to merge the changes
from `fix-foo' into `trunk' as usual (taking care of the ChangeLog
issue.)

If now you wish to work on a new micro-feature:

cd ..    # from `my-playground'
bzr branch --no-tree fix-bar
cd my-playground
bzr status  # Test that you don't have pending changes!
bzr switch ../fix-bar

Note that, within a shared repository, you can organize your branches as
you wish, so it is advisable to make a directory `delayed-changes' and
create your mini-feature branches there.

[snip]

-- 
Óscar