couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Wed, 22 May 2013 01:29:45 GMT
On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <randall.leeds@gmail.com> 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.
>
> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
>
> 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.

Mime
View raw message