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 >>>> >>>> >>>> >>>> >>>> >>> >>> >> > >
