Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com
 designates 74.125.92.27 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=nyBzwZPyDdYvFsb8UI+GF8jo9FQZIYlh2AFSRFLbjJiq+XEPujluA0jJ6QuRj2vEMF
         rZK/qRhJ+M2bY2lSJnJ0VBy2b96OuYAxwC3c/YtjtyK7lKWBM+NKHR96ubMKuqAGoKYR
         g7nCSZ8tnC/CLIZvRYQ38LXJ+lUV+YBCeWjl4=
Message-Id: <114C0649-73F2-4013-AFE2-67C961B53FFC@gmail.com>
From: Adam Kocoloski <adam.kocoloski@gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: <e2111bbb0905130710p2f0466d0sdabca9aafa1ed8a@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Release 0.9.1
Date: Wed, 13 May 2009 10:16:24 -0400
References: <e282921e0905041832j40bcf06ax1476d97cd81df71f@mail.gmail.com>
 <265DE325-6C9D-406A-BFDD-0D5CB7D4BAAA@gmail.com>
 <5FA292E9-7EB1-4F77-BCC8-9C094E5CB102@apache.org>
 <64F970DF-B005-4076-BE63-7362EE31679D@apache.org>
 <2BC6AA55-53D2-404D-BBF8-D9B7218F9D05@apache.org>
 <e2111bbb0905130710p2f0466d0sdabca9aafa1ed8a@mail.gmail.com>

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