Cherry-picking

Tue Jun 8 17:07:29 UTC 2010

On Tue, June 8, 2010 11:29, Mike Meyer wrote:
> On Tue, 8 Jun 2010 11:11:30 -0500
> "David Dyer-Bennet" <dd-b at dd-b.net> wrote:
>> On Tue, June 8, 2010 11:02, Mike Meyer wrote:
>> > On Tue, 8 Jun 2010 10:23:58 -0500
>> > "David Dyer-Bennet" <dd-b at dd-b.net> wrote:
>> >
>> >> I thought this should be a simple issue, but I'm reading all sorts of
>> >> articles on this out on the web, and playing with toolsets, and none
>> of
>> >> them will do this in any way that seems safe or natural to me.  I
>> must
>> >> be
>> >> missing something (perhaps in my definition of "natural").
>> >
>> > Masklinn pegged it - your definition of "sane-and-sensible" aren't in
>> > line with industry best practices.
>>
>> Well, I have to deal with the reality before me.  But I haven't actually
>> seen things work differently in practice much of anywhere.
>
> I have. Actually, even the nearly unplanned place I worked had a
> better workflow than what you've described. The problem was the client
> would make apparently arbitrary changes in what features they wanted
> 24 hours before the release, so cherry-picking to move stuff from
> development to release - and vice versa - was a regular part of the
> release cycle, no matter how good our planning and workflow were.

Yes, there's only so good that it's worth being, because uncontrollable
outside forces keep disturbing it.  Any workflow that's brittle won't be
your friend in the real world for logn.

>> >> Suppose that a small team of developers are using Mercurial with a
>> >> central
>> >> repository that they've all cloned off of.  Suppose that the
>> "default"
>> >> branch is being used for relatively free-wheeling new feature
>> >> development,
>> >> and the "release" branch is used for the latest release (software is
>> >> built
>> >> and released to the company every week or so).
>> >>
>> >> Now, suppose user u1 makes three changes to the "release" branch,
>> which
>> >> I
>> >> will call a, b, and c (three commits), and then pushes his changes to
>> >> the
>> >> central repository.
>> >>
>> >> And suppose user u2 makes two changes to the release branch, which I
>> >> will
>> >> call x and y (two commits).
>> >>
>> >> And, finally, that user u2 is told to build an actual release,
>> >> containing
>> >> all the work done on the "release" branch *except for change b*.
>> >
>> > Having worked in such poorly-planned (in the sense that there wasn't
>> > any real planning about what went into a release until it was time to
>> > prepare the release), I can say with some confidence that u2 is either
>> > working very hard to change things, or looking for a new position.
>>
>> Are we somehow not communicating here?  Everything for the release is on
>> the release branch; all that's wrong is that, somehow, *one* thing got
>> on
>> the release branch that wasn't supposed to be (or maybe management
>> changed
>> their minds at the last minute).  That happens in the real world of
>> release engineering that I've seen ALL THE TIME.  (It might be one out
>> of
>> 75 in the real world, rather than one out of 4, but that one is
>> frequently
>> still there.)
>
> Yes, we're not communicating. I misread what you wrote. I thought you
> wanted *all* the changes on the *default* branch except b. My
> apologies for a *really* bad misread.

<great relief>.  I wasn't sure if I was much more confused than I thought,
or what.  Sorry to have been confusing.

>> If you're saying that Mercurial only works in an environment so
>> idealized
>> that nobody ever makes a mistake, and management never changes their
>> minds, well, then it's not usable in the real world.
>
> You're right, they do, and mercurial handles them with the "backout"
> command. Use hg log to get the changeset number, then run "hg backout
> -r ###" to take it out of the working copy, and commit that. Pretty
> much exactly like I'd do it in svn, perforce, cvs, git, etc.

Thanks to you for this, too.  Yes, I've made that work.  I thought I'd
looked at backout earlier and run into too many limitations, but knowing
that it was the right solution for this problem, I beat my head against it
harder and broke through, and indeed was able to do exactly what I wanted
in my example, very easily once I figured out how.

>> >> What are sane-and-sensible ways to do this in this general
>> environment?
>> >
>> > If you want a sane-and-sensible way to do something, it really helps
>> > if you are trying to do something sane-and-sensible. There are a
>> > number of different ways to change your general environment, but the
>> > best ones all involve deciding what features you'd like in a release
>> > before you start developing them.
>>
>> My example did that.  It's just, somebody screwed up one commit, or
>> maybe
>> management changed their mind about one thing.
>>
>> Lots of best-practices workflows change what's in a release at the last
>> minute.  One common approach is to make releases at fixed (frequent)
>> dates, and put in everything that's ready by the cutoff date; generally
>> there's a big meeting to decide which things are ready for release
>> shortly
>> before that cutoff.
>
> Again, I misunderstood what was going on, and again it's entirely my
> fault, and I apologize. I thought that you were cherry-picking the
> default branch to get a release, not fixing a glitch on the
> release. While I still think you could improve your workflow - it
> reminds me of places I've worked where management couldn't convince
> developers to create branches - it's not nearly as bad as I
> thought. The ability to cherry-pick is required, but doing it should
> be the exception, not the rule.

I'm sure we could improve our workflow too.  But getting us onto
Mercurial, if I manage it, will me a major accomplishment here in and of
itself, and will I think lead to more flexibility on some other workflow
issues in the future.  I hope.

We're doing software for internal users (people in our company) only, so
we have somewhat different time-scales and such than places I've worked
before.  And I'm completely new to Mercurial (been using it myself for a
few months, but simple one-person projects don't get me into any of the
hard cases) and trying to deal with everybody here asking "How will we do
x?" for many Xs.

Well, worst case I will have learned Mercurial decently myself.

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info