changesets and files in bzr vs cvs

[John Arbash Meinel]

Stuart McGraw wrote:
> [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.

Most would argue for that. Note that for reasonably simple changes, you 
can still use a:

  bzr shelve
  # make new bugfix
  bzr commit
  bzr unshelve

workflow, rather than creating an entirely new branch.

There is also:
http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reusing-a-checkout

Which would allow you to not have 2 copies of the working tree files. 
"Working-in-place" but using different branches as appropriate.


...

>> 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. :-)
> 

Well, shelve allows you to select hunks, but yes, if the exact same 
lines are changed by 2 fixes then no tool is really going to help you 
separate them out. There isn't a huge problem with marking the commit as 
"Fix X & Y" at that point, though.


...

>> 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?
> 

bzrlib will store the data, transmit it for branching/merging/etc, but 
the 'bzr' ui doesn't expose it in 'bzr log', 'bzr annotate' or have a 
way to describe it for "bzr commit".

Our UI is generally not very interactive, since for a command line app, 
we feel that prompts don't make really a great ui. (Especially for 
something that may get scripted.)

I'm also not sure that there is a huge benefit. I implemented the basics 
so that people could play with it. But if you are looking for when the 
"fix X" was done, it seems easier to find in the global log. (bzr log -r 
1..-1 --message "fix X"). One thing I really didn't like with CVS is 
that it was near impossible to see from a global level what has been 
going on.

I guess I personally rarely care what is happening to a specific file, 
outside of what is happening to the whole project. Changes are rarely 
restricted to a single file (especially when you have a test suite to 
update at the same time).

If you use feature branches, then you can still get some global-level 
versus fine-grained granularity using "bzr log --long" versus "bzr log 
--short". The fine-grained work is done on feature branches and merged 
into the mainline, so it is hidden by --short with just a summary.

> 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.)


John
=:->