couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Wed, 22 May 2013 16:31:06 GMT
It sounds like you have a very good idea of how to solve our problems! I
suggest you run with it! :D As you mention, probably best to spin this out
to another thread. (Or tac it on to the end of the existing "[DISCUSS] Git
workflow" thread. We really need to drive that to conclusion as soon as
possible.) Ideally, once we've agreed on what we want to do here, someone
moves it to the wiki, and we let it mature there for a while, before moving
to the docs.

Randall, can you also help me prepare the commands / instructions to send
out at the various points during the release cycle? I'd like to have
copy-and-paste-able things people can use to help them get things sorted.

On 22 May 2013 02:29, Randall Leeds <> wrote:

> On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <>
> wrote:
> > Here's a diagram. In this I show a feature branch landing on master
> > and a backport of it landing on 1.3.x, but if we follow the procedure
> > I'm suggesting I think it can even be easy to keep track of
> > cherry-picked backports.
> >
> >
> >
> > The fancy things here are
> >   * merge-base: to find the common ancestor
> >   * --no-commit: so NEWS and CHANGES can be reconciled atomically with
> > respect to what the git logs will say is unmerged
> >   * -Xours: so that we can merge release branches to master *without*
> > code changes, just to mark a point in history so that a future
> > merge-base will only show us what hasn't made it into NEWS and CHANGES
> > since we last did this.
> This last one is the key piece. By using the "ours" merge strategy we
> can mark at point in history where the *history* is said to be
> reconciled (we've updated NEWS and CHANGES in both merge parents)
> without accidentally forward-porting code changes. We can record new
> merge bases for the release branches vis-a-vis master, which makes
> reading the logs for NEWS and CHANGES maintenance easier, and at the
> same time we record the current state of NEWS and CHANGES.
> But maybe I'm overthinking it since one alternative is to just update
> NEWS and CHANGES whenever we make commits. However, I think if we just
> merge releases to master whenever we make a backport or a release then
> it will be a very quick and painless process to update NEWS and
> CHANGES when it comes time for 1.4.x.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message