changesets and files in bzr vs cvs

[Eugene Wee]

Hi,

bzr commit allows for selected files/directories to be specified. I tend 
to commit at one shot so I never tried this out myself, but it sounds 
like what you want. Enter "bzr help commit" for more information.

Regards,
Eugene Wee

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