Re: VC and bzr.

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 22 Apr 2010 21:31:44 +0200
> 
> Merging from trunk into a feature branch is not a serious problem (it
> creates some noise on the history with the associated slowdown on bzr's
> responsiveness, but that's all). But pushing to trunk after merging is a
> serious problem as you (Eli) discovered:

This is a misunderstanding.  No one was suggesting such a workflow.

The suggestion was to commit locally more, and commit remotely less.
Which in practice means to work on a local branch, then merge back to
trunk when the changes are ready.  To avoid clutter in the history
log, I further suggested not to merge from mainline as long as one
works on a single feature in a local branch.  I find these merges
necessary only when I work for months on some very invasive feature.

> The solution for the annoying slowness of commit operations is the smart
> server

I'm not sure I will be alive, or around, long enough to see it happen.
It is ridiculous that it took me less time to develop bidirectional
display than it takes Savannah hackers to set up a server.  Perhaps
I'm too stupid to understand how this is possible.