changesets and files in bzr vs cvs

[Stuart McGraw]

John Arbash Meinel wrote:
> Stuart McGraw wrote:
[...]
>>> 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.)

What about something like
   bzr message "per file commit message text" file1 file2 ...
which would stash the text away somewhere, appending
to any previously stashed text.  When file1 is committed
the stashed text forms the per-file commit message for
file1.  Of course additional support is needed, like
   bzr message -c file1 file2... # clear stashed messages for files
   bzr message -e file1 # Run editor on stashed text.
   bzr message file1 file2... # Display the stashed text for the files
etc.

I've often wondered in the past if something like this
would have been useful for my CVS use to replace the use
of a changelog file.

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

I tend to be more anal about documentation then many
of my colleagues but I like to record both a summary
"fix bug X" and an explanation (skipped when obvious)
about how it was fixed that relates to the actual lines
changes.  I suppose it could be argued that that information
is more appropriate for code comments.

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

Will look into this more.

Thanks for the info.