[Python-Dev] Hg: inter-branch workflow

[Ben Finney]

Neil Schemenauer <nas at python.ca> writes:

> Regarding collapsing multiple comments (and rewriting history in
> general), I feel there are two main schools of thought. One school
> considers the development history of a change important and that it
> should be preserved: every step and misstep of development should end
> up in the public repository.

Yep, that's the school I'm in. Other people don't get to say what I
would find useful, and the cost of having data there is very low
compared to the inability to re-create it at the times when it's needed.

> The other school, which I am a member of, considers a logical
> development sequence more important than actual development history.

That seems to be an artefact of VCS tools which force you to choose
between those two. The reason I prefer Bazaar is that it gives me both
without compromising either.

> I like to see a feature or fix developed in smallish, logical steps
> and I'm willing to spend a lot of time to rewrite patches to make it
> happen. IMO, future maintainers will thank you for the effort.

Right, and those logical steps are done as merges from the feature
branch into the trunk (substitute those names as you like). I consider
the merging from one branch to another as the time to decide how to
present my VCS work for others to view.

I haven't heard a useful case for rebase that I don't get with Bazaar's
merging, default history presentation, and shelve capability. And all of
that without ever having to re-write history – nor even choose what
valuable information to lose.

-- 
 \      “The way to build large Python applications is to componentize |
  `\             and loosely-couple the hell out of everything.” —Aahz |
_o__)                                                                  |
Ben Finney