Bazaar Workflow

[马旋（SuperMMX）]

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

Hi, Philippe Lhoste <PhiLho at GMX.net> :

On Sun, 05 Apr 2009 16:03:42 +0200
Philippe Lhoste <PhiLho at GMX.net> wrote:

> Additional remarks:
> - I use currently Bazaar mostly for small personal projects. At work, we 
> have a rather large code base, managed with Perforce, which is a fine 
> SCM (central workflow). That's why I wondered how usable is the "clone 
> project for each small change/bug fix" method for such large code base, 
> not to mention issues with IDEs (not easy to change paths on run 
> configs, etc.).

Using only one lightweight checkout and switching between different branches
in a shared repository can solve this problem. Because you will have
only one working tree. And you don't need to change any path in your IDE.

> - Perforce allows to group changes (modified files) in changelists: so I 
> can have some files opened for a feature implementation, and a couple of 
> other changelists for various in progress bug fixes.
> - Bazaar doesn't have this (you don't have to check out a file before 
> editing it, which is nice) but allows to select files to commit. A bit 
> heavy handed on the command line (I would appreciate to have a file 
> (listing files to commit) per task, and specify it at commit time), but 
> I recall having seen a plugin using the commit file (opened if not 
> giving a -m option) where you can select the files to commit.

I am using Emacs as my editor and there is vc-dir mode availabe to interact
with various Version Control tools, in which you can mark (select) severl
files and commit them only.

And sometimes I use commandline. In the project root, I will run "bzr status"
to get all the changed files, then you can just copy/paste the files you 
want to commit as the bzr commandline options.

> Moreover, I am confused by the other answers telling you can't "merge 
> with uncommitted changes in your local working copy.", I wonder what I 
> did in my previous experiment. I should make more thorough tests (with 
> conflicting edits?).
> 
If you have uncommitted changes in your working tree, it is not in a 
clean state to merge, because merging will change the working tree,
IMO, it is not that obvious to look at the merge result. 

But you can give the option --force to force the merging, although
you can only commit them all in one, no partial commits.

- -- 
A. Because it makes the logic of the discussion difficult to follow.
Q. Why shoudn't I top post?
A. No.
Q Should I top post?

A: Because it destroys the flow of the conversation
Q: Why is it bad?
A: No, it's bad.
Q: Should I top post in replies to mailing lists? 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)

iEYEARECAAYFAknYviIACgkQYjhzyV/TMxt1OwCghYqDdrBiyznQMGINuQCeCFbF
z/gAn2yps+MpShmPotM3VM08I+ifMtCc
=qJik
-----END PGP SIGNATURE-----