Workflow problem resulting in useless commit messages

[John Arbash Meinel]

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

Andrew King wrote:
> Hi everyone,
> 
> I am sure I am missing something fairly obvious, but we are having real
> issues with our current workflow, and I am sure there must be a way to
> do it better than we are currently.
> 
> The situation:
> 
> We have a mainline called trunk.
> 
> We have a number of developers, each using their own branched version of
> trunk where they do work, lets say adding feature X.
> 
> Lets say I make some progress on the feature, then I commit. 
> 
> I then try and keep up to date with trunk, because I want to have as few
> conflicts as possible in the long term. So, I have to use bzr merge,
> resolve conflicts, then commit. Commit message is usually "Merged from
> trunk". Repeat this a number of times. I don't use pull, because then I
> have not committed my work, and if I get some complicated conflicts that
> I dont' resolve correctly the first time, I am in danger of losing my work.
> 
> Then, I am done with the feature. I want to push to trunk. I use bzr push.
> 
> I now end up with a nested commit tree, where I am responsible for all
> the changes that have been done since I started feature X.
> 
> ie.
> 
> revno something
> committer: me
> adding feature X.
>     
>      revno blah merged from trunk
>      committer: me
>      
>          revno blah
>          committer: someone else
> 
>           revno: blah
>           committer: yet someone else
>           some other feature
> 
>     revno blah
>     committer: me
>     some work on featureX
>     
> 
> If I want to avoid this I have to:
> 
> do a clean branch of trunk.
> bzr branch /path/to/trunk trunk-clean
> 
> do diff trunk myBranch
> 
> apply the diff to trunk-clean
> 
> 
> Which no one ever does.
> 
> What are we missing? This has to be a pretty common workflow, but there
> doesn't seem to be a clear way to support it.
> 
> should we be using bzr send or something instead of push?
> 
> should we be using rebase or something?
> 
> Cheers,
> Andrew

Simply put, I would not use "push" to the trunk, especially if you
aren't going to use "pull" to your feature branch.

The way I would recommend is to have 2 working trees. One is a (heavy)
checkout of trunk, and the other is your feature branch.

Then when your feature branch is done, you

cd ../trunk
bzr merge ../feature-foo
# run tests
bzr commit -m "Merge feature foo"

That is effectively how we do bzr development (though we have a script
do the run tests && commit for us.)

If you do "bzr log --short bzr.dev" you get to see all of the features
landing into mainline, without any "try this", "oops", "revert and try
that", "merge trunk", etc. However, that information is still there.

In the end, push & pull are meant as mirroring operations. If you don't
want your feature branch to become trunk (you don't pull) I don't think
you want your trunk to become your feature branch (you shouldn't push).
Instead, merge & commit into the trunk (and possibly push that if you
don't want to use a checkout).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklBH6MACgkQJdeBCYSNAAP01gCfYOPDlkFKGuAaF7DK4EWasFP3
1m0An3Muhltl34o4QquHPBrVeSmQDkY4
=nFs5
-----END PGP SIGNATURE-----