Mercurial and Agile

[Mike Meyer]

On Thu, 02 Jul 2009 02:28:45 +0200
Mads Kiilerich <mads at kiilerich.com> wrote:

> Bret Naylor wrote, On 07/02/2009 01:21 AM:
> > Short Question:  Why is it so hard to cherry pick individual 
> > changesets and only move those across repositories?
> 
> Short answer: Because it _is_ hard.

And generally a bad idea. You do want tools that support it, because
sometimes you have no other choice, but if it's a regular part of your
process, you should seriously consider revamping your process.

> Darcs claims they can handle cherrypicking - and sometimes they can. 
> Perforce can do it reasonable well too.

I don't have an online writeup of why, but read Laura Wingard's book
"Practical Perforce" for information. Yes, her examples all use
Perforce, but there's lots of good information about SCM best
practices in that book as well.

> > The problem is, we can't choose a changeset from one of the group 
> > repositories and push it into QA by itself.  it always has to have all 
> > of its parents.  Some of the parents may not be ready for QA and so 
> > this causes a problem for us.
> 
> Unfortunately changesets can't be handled the way you want to. They 
> might - and will - have intended and unintended dependencies, both 
> explicit and implicit.

What it boils down to is that if A & B are interdependent changesets
with AB representing the version in which B is "ready", then AB-A is
*not* the same software as AB, so what you know about AB isn't
necessarily true of AB-A. You either take AB and ignore A, or you
start testing from square one with AB-A.

I once had a client that wanted monthly releases, and we would
generally plan them about three months in advance. But they would
*inevitably* change their mind, and ask for some subset of what was
planned for each release. We couldn't convince them this was a bad
idea, so we eventually moved the release meetings back a week, and
lost a week every month to creating a "cherry-picked" branch for the
release and repeating all our in house testing.

> I think the "workaround" you describe is a fine solution. If you want to 
> be able to separate changes later on, then you have to keep them 
> separated from the beginning and all the way to the point where you make 
> the final integration and merge them. In Mercurial you can do that by 
> having separate repositories or branches.

+1.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org