Thanks, Paul -- Jan included those instructions in this thread too. I don't usually keep the entire repo checked out at any given time, so I needed to do something a little bit different. I looked back in my history and saw

 4183  svn sw https://svn.apache.org/repos/asf/couchdb/branches/0.9.x
 4184  svn log
 4185  patch -p1 < /tmp/patch.txt
 4186  svn merge -c 765364 trunk branches/0.9.x
 4187  svn help merge
4188 svn merge -c 765364 https://svn.apache.org/repos/asf/couchdb/trunk .
 4189  svn diff
 4190  svn ci

So clearly I was struggling with the precise incantation, but I'm pretty sure I got it figured out in 4188 and 4190. I'm just wondering why the trunk revision still shows up as an eligible rev to merge after I did that.

Adam

On May 13, 2009, at 10:10 AM, Paul Davis wrote:

Adam,

There's an email from Noah in an older thread (gmail search terms:
noah cherry picking) that gives a good reference, but the general
incantations are something like:

// Do the merge:
svn merge -c $REVISION trunk/ branches/0.9.x

// Block the merge
svn merge -c $REVISION --record-only trunk/ branches/0.9.x

Paul

On Wed, May 13, 2009 at 10:05 AM, Adam Kocoloski <[email protected]> wrote:
Hi Jan, thanks for doing this. I believe all of my commits in the changeset you listed below are good candidates for merging to 0.9.x. I could use a little help with the svn incantations, though -- I thought I already merged
r765364 into 0.9.x:

http://svn.apache.org/viewvc?view=rev&revision=765387

Do you know what I did wrong?  Cheers, Adam

On May 13, 2009, at 9:42 AM, Jan Lehnardt wrote:

Hi,

I went through the list* of eligible change sets for the 0.9.x
branch to get closer to the 0.9.1 release.

I blocked or merged all of my commits, and all new stuff
from Damien, Chris, Adam, Paul and Noah. I'm sorry if
I stomped on anyone's feet here, but I figured I might as
well go through the whole list while I'm in there.

I blocked anything that has remotely to do with "new"
or "refactor" and only merged a few fixes.

We still do have some eligible change sets open and I
do believe all of them should be merged into 0.9.x, but
I don't feel qualified enough to comment on the stability.

These change set are:
------------------------------------------------------------------------
r758093 | damien | 2009-03-25 00:48:33 +0100 (Wed, 25 Mar 2009) | 1 line

Fix for crash when compacting an empty database
------------------------------------------------------------------------
------------------------------------------------------------------------
r763858 | damien | 2009-04-10 04:21:37 +0200 (Fri, 10 Apr 2009) | 1 line

Fixes for leaked file handles, with test.
------------------------------------------------------------------------
------------------------------------------------------------------------
r765364 | kocolosk | 2009-04-15 23:21:23 +0200 (Wed, 15 Apr 2009) | 2
lines

URL-encode attachment paths during replication

------------------------------------------------------------------------
------------------------------------------------------------------------
r766338 | nslater | 2009-04-18 17:20:00 +0200 (Sat, 18 Apr 2009) | 1 line

create /var/run/couchdb during init script
------------------------------------------------------------------------
------------------------------------------------------------------------
r766883 | damien | 2009-04-20 23:34:46 +0200 (Mon, 20 Apr 2009) | 1 line

Fix for process leaks with retrying compactions.
------------------------------------------------------------------------
------------------------------------------------------------------------
r771474 | kocolosk | 2009-05-05 00:25:23 +0200 (Tue, 05 May 2009) | 2
lines

standalone attachment GETs should respect "rev" qs param

------------------------------------------------------------------------
------------------------------------------------------------------------
r771480 | kocolosk | 2009-05-05 00:36:46 +0200 (Tue, 05 May 2009) | 2
lines

use revisions when replicating attachments.  Closes COUCHDB-337

------------------------------------------------------------------------

Adam, Damien, Noah: Can you comment on your changes
and whether they should go into the 0.9.x branch?

When we're through with these, I believe we're ready to start
the 0.9.1 release.

--

Finally, and I'm the first to follow, it'd be great if we all could
get into the habit of either merging or blocking commits to
trunk for the 0.9.x branch.

As a reminder.

Blocking REVISION:

 svn merge -c REVISION --record-only trunk branches/0.9.x
 svn commit branches/Y.Y.x -m "blocked REVISION from trunk"

Merging REVISION:

 svn merge -c REVISION trunk branches/0.9.x
 svn commit branches/Y.Y.x -m "merged REVISION from trunk"


Cheers
Jan
--
* for i in `svn mergeinfo trunk branches/0.9.x --show-revs eligible`; do
    svn log -r $i;
 done



On 6 May 2009, at 19:38, Damien Katz wrote:


On May 5, 2009, at 9:12 AM, Adam Kocoloski wrote:

On May 4, 2009, at 9:32 PM, Chris Anderson wrote:

Devs,

Are we ready for 0.9.1? My pet patch is in and backported, how about
yours?

I wonder if we should try to shore up the JIRA records of what's in
0.9.1.  Currently I see

COUCHDB-306 Wacky error responses to malformed documents
COUCHDB-310 Fix hardcoded redirect to "/_utils/"
COUCHDB-311 Wrong encoded _external error message
COUCHDB-322 Specifying reduce=true on a view with no reduce does not
cause an error.
COUCHDB-334 With deferred commits and 100+ active dbs, CouchDB can lose
uncommitted changes
COUCHDB-342 url-encode attachment paths during replication

as well as one open ticket targeted for 0.9.1:

COUCHDB-328 [patch] allow futon reduce textareas to contain accidental
white spaces.

I'm sure there are other resolved/closed tickets missing from that list.
 As far as my work is concerned, I think

COUCHDB-337 attachments from old/conflict revisions are not accessible
via standalone API

would be a decent candidate for backporting. It's a simple fix, but the fact that we ran like that for months without anyone noticing probably means
it's low priority.  Cheers,

I think the fix is an important one. The big problem isn't the failures, it's when it doesn't error out that's the problem. It can put the wrong attachment data into another revision, which is a form of data corruption.


Adam











Reply via email to