changesets and files in bzr vs cvs

Stuart McGraw smcg4191 at frii.com
Tue Jan 29 18:16:34 GMT 2008


I have been reading about DVCS and it sounds really good.
So I have been playing around with Bazaar.  There is
something I do now with CVS that I don't see a way to
do with bzr.  Apologies for the length.

Disclaimer: I am a pretty casual and naive user of SCM.
I use it mostly for my own small projects and a couple
of public ones to which I have not managed to attract
any other contributors yet.  :-(

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.

In CVS I deal with this somewhat awkwardly by
maintaining a change log file that notes that change
"fix bug X" was made to files A and B and that change
"fix bug Y" was made to files A and C,  When I commit I
copy the change log text for use in the commit messages
so the files are committed in a relatively short period
of time with messages like:

    File A:
	fix bug X
	fix bug Y
   File B:
	fix bug X
   File C:
	fix bug Y

(Actually i enter the changes in a little database app
and it generates the change log file from which I copy
the commit messages.)

Now with Bazaar, I don't think I can work this way since
there is one commit message that applies to all files
committed.  Thus I could commit files A, B, and C with the
commit message "fix bug X, fix bug Y" but that looses the
information that the file C changes have nothing to do
with the X fix.

I think the accepted way to do this is to make the two
fixes sequentially: edit A and B, commit with "fix bug X",
then edit A and C and commit with "fix bug Y".
But I often find this hard to do.  Not so much of a
problem if the fixes are small localized changed but when
fix X and fix Y are extensive and effect many of the same
code lines, I find it much more efficient to consider both
fixes when editing the code.  Sometimes, the changes
actually are interdependent and hard to separate into
"this is for fix X and this for fix Y".  And as I said
above, it feels disruptive to postpone making a change
now when it is fresh in mind.

Or I could commit A and B with "fix bug X, partial fix
bug Y" and then C with "remainder of fix Y" but this
spreads bug fix Y out over two (or more) commits so
doesn't seem ideal.

To put a different way, I seem to find many cases where
there is a many-to-many relation between fixes and files
but Bazaar's model seems to assume a one-to-many relation
between fixes and files.

So I wonder what the best way to deal with this is?

(As I said, I an very new to Bazaar so apologies if
I am missing something obvious and need to do more
reading.  Pointers welcome!)






More information about the bazaar mailing list