changesets and files in bzr vs cvs

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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


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.

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.

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

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

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHn3ouJdeBCYSNAAMRAiG6AKCXH8nKfMPuOtqt03tCFZgKX8dJvQCgihxd
WdrWT2LbmT1tc28qWxFptGg=
=vxMY
-----END PGP SIGNATURE-----