On 09/24/2010 10:25 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> Since this is my first batch of bzr checkins that I think have made, it
>> would be great if folks could give it a try. I also checked in past
>> diffs I had posted here.
> Maybe I'm mistaken, but from the logs it seems to me that you directly
> pushed to trunk from within a task branch, meaning you did
> bzr push bzr+ssh://CEDET-URL/code/trunk
> while still in the 'similarp' branch. This is not a good idea with
> bzr. Maybe this is OK as long as there are no merges from trunk
> involved, but in any case, I'd avoid it. In Bazaar, revision numbers are
> always specific to a certain branch. If you push a task branch upstream,
> this will make upstream a mirror of your task branch, possibly with new
> revision numbers. This can lead to a strange history display for other
> developers which are again merging your changes from trunk (because they
> are in fact merging the history of your task branch).
> Bzr encourages a 'merge to local trunk branch and push' workflow: When
> you have finished some feature on a separate task branch, usually
> involving several smaller commits, you merge those changes into the
> trunk and then push. This is described in Lluis' docs in the last
> paragraph titled "Merging into the mainline". You would then choose a
> commit messages which shortly summarizes the changes you did in that
> task branch; in the normal history view with 'bzr log', you'd only see
> that summary, not the single commits you did in that branch.
> By doing so, you get a hierarchical history, which can be seen fully by
> using "bzr log -n0" instead of the default "bzr log", which uses "-n1".
> Just try those two commands on the Emacs repo to get an impression. The
> latter will only show you the merge messages ("flat view"), while the
> former will also display the commits contained in those merges (those
> are indented).
> If you think this stuff is overkill, I'd say just work directly on the
> trunk; this pretty much gives you a workflow like an 'offline CVS', in
> which you explicitly have to push changes upstream.
I figured some of that out after the fact. I had used the checkout
branch technique first just to get some little stuff in. That meant I
head 'trunk' as a checkout. When I went to merge similarp into trunk it
failed (as far as I can remember) because it wasn't the right kind of
trunk. Reading through I saw how push worked, tried it, and it did stuff.
I suspect I would use a checkout of trunk for most things, since I do
lots of small patches, but I like the idea of having branches for bigger
tasks. I then am stuck with deleting trunk each time I do an operation?
The nice thing about my CVS workflow was that I just pointed Emacs at
it, and I was good to go. All the branching means I have to restart
Emacs all the time. If I'm deleting trunk a lot that would be a challenge.
I'm sure there's a good workflow to use. I just need to break away from
my old one.