incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Release 0.9.1
Date Wed, 13 May 2009 14:10:14 GMT
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 <kocolosk@apache.org> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

Mime
View raw message