changesets and files in bzr vs cvs

[Stuart McGraw]

[Oops, sent copy to John instead of list as I intended,
here is list copy.]

John Arbash Meinel wrote:
> Stuart McGraw wrote:
>>[...]
>> I often find that when I am editing a file to implement
>> a bug fix or enhancement, that I will see something else
>> at the same time that needs doing (fix unrelated comments,
>> make a change in support of some other fix, etc).  (I'll
>> use the word "fix" to mean any change including enhancements,
>> new features, refactorings, etc)  It feels very disruptive
>> to my thought/workflow to forgo making these changes now
>> when they are fresh in my mind, and to come back and do
>> them later in a separate commit.
>>[...]
> 
> There are a few ways to handle it:
>
> 1) Work in feature branches as much as possible. This *is* a bit more
> disruptive, and feels like a bit of overhead for simple projects. But if
> you get used to it, you might find that you really really like it.
> 
> So when you are working on something and you find you need to make a
> quick bugfix, you create a branch, write a test, fix the bug, and
> commit. Then you have everything independently done.

I have a feeling this might be the real answer, and I
just need to get used to doing things this way.

> 2) If you've realize you just made the fix, you can still use a feature
> branch with:
> 
>  bzr branch . ../bugfix_x
>  cd ../bugfix_x
>  bzr merge --uncommitted ../original
>  # Now clean up the bugfix, add your tests, etc
>  bzr commit -m "bugfix for X"
> 
> (the key point here is the "merge --uncommitted" to pull across your
> working tree changes into another branch.)
>
> 3) Use the nice functions given by "bzr shelve". Shelve is a plugin
> provided by "bzrtools", which lets you put change hunks "onto a shelf"
> to pull back out later. So you would do something like:
> 
>   # oops, made a bugfix to foo, but have pending work in bar
>   bzr shelve bar
>   bzr commit -m "Fixing X for foo"
>   bzr unshelve --all
> 
> It has problems with binary files, and it only can unshelve exact
> matches, which is why it isn't a core feature yet. But often it is helpful.

If the lines touched by fix X are exclusive of
those touched by fix Y, this will help I think.
But when they are not then I am back at square one.
And I wonder if interactively stepping through a list
of changed lines is less onerous that just applying
the fixes sequentially to begin with.  I can see
its utility when lack or foresight is present
though (an all too common occurrence for me. :-)

> 4) Partial commits. If your changes really are separated by file, then
> you just do:
> 
>   bzr commit -m "Fix X" foo
> 
> Which won't commit the changes to "bar".

Except in the situation I often find myself in, they
are not cleanly separated by file.

> 5)  Per file commit messages.
> 
> This is still a bit in "beta". bzr-gtk supports it if you set the flag
> to enable it. And it will show the per-file messages in the "Viz" view,
> as well as for "gannotate".

This I think is what I need to maintain a log history
with the same detail that I currently do, if I don't
want to accept the discipline of implementing each
fix separately and sequentially.

When you say "bzr-gtk supports it", does that mean the
capability is in bzrlib but not currently accessible
though the bzr command line tool?
If so is there any plan or schedule when it will be?

I haven't tried using any of the gui tools yet.  I wanted
to learn the basic command line stuff first (and would be
hesitant to rely on features not available in the basic
tools, anyway.)