Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 74.125.83.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=NFhfdHkqMy9+yHDAoNhdRn68fChj0MMC0FEzqCFp6kjRnfwqL64RhmvKN0zxuymzzI
         0f9vp4Xh8QaaDQYldMQMZ04wqlqbVtthxsoZn51rhrvJrd1kgC1n0EQJ3nPjn548kk1x
         vYvEdSY3fjzkYziLM6yWJzgZ6smylWdFykliI=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=2qZNJV=P7TmrW+d2JkDSZW9FUPv0MNxvRN_vq@mail.gmail.com>
References: <AANLkTikQ1XjHC94x8JuF7HFeEhjrQLBSCBgd_9B-SuZG@mail.gmail.com>
 <AANLkTimhCw=d_6ed7R9uq5OKM0tUGrXema=qJeisDGQJ@mail.gmail.com>
 <AANLkTinYRXaPGW7PjLgP9Zjb6WZw3rv6S=zC20jL_Tf7@mail.gmail.com>
 <AANLkTi=2qZNJV=P7TmrW+d2JkDSZW9FUPv0MNxvRN_vq@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Sun, 26 Dec 2010 18:01:47 -0500
Message-ID: <AANLkTi=9cP6CR346qfG2KtbxhcgdsgcJwWHyjpd1tVzL@mail.gmail.com>
Subject: Re: Source tree refactoring - TESTERS NEEDED
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bchesneau@gmail.com> wrot=
e:
> On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <paul.joseph.davis@gmail.com>=
 wrote:
>> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bchesneau@gmail.com> =
wrote:
>>> On Saturday, December 4, 2010, Paul Davis <paul.joseph.davis@gmail.com>=
 wrote:
>>>> Heya,
>>>>
>>>> I've just finished getting the refactoring of the source tree to be
>>>> more compliant with OTP source code layout. This is a pretty big move
>>>> so I'd like at least a couple other people to test this. If you have a
>>>> platform that is not OS X or Ubuntu, consider this an extra special
>>>> request so that we have confidence that I haven't broken one of the
>>>> uncommon platforms.
>>>>
>>>> The repo for the scripts and patches are at [1]. You should be able to
>>>> get a fully refactored couch with:
>>>>
>>>> =A0=A0 =A0$ git clone git://github.com/davisp/couchdb-srcmv.git
>>>> =A0=A0 =A0$ cd couchdb-srcmv
>>>> =A0=A0 =A0$ ./srcmv.py
>>>>
>>>> Once you have that, there's a couchdb.git subdirectory that is a
>>>> checkout of the entire source tree. Once there, you can build and test
>>>> couchdb as per normal. Also, I would appreciate anyone that goes the
>>>> extra effort and runs the install into a tmp location and runs the
>>>> Futon tests on the installed version to make sure everything still
>>>> passes.
>>>>
>>>> Ideally I'd like to get this into trunk fairly shortly so that it has
>>>> as long as possible to sit in trunk before we cut 1.2.x. Let me know
>>>> if there are any comments or complaints on it.
>>>>
>>>> Paul Davis
>>>>
>>>> [1] https://github.com/davisp/couchdb-srcmv
>>>>
>>>
>>> After thinking about it, I don't see the point of having a script to
>>> maintain patches, + patches coming with. It make review hard compared
>>> to having a branch dedicated to this refactoring. Also it stops
>>> somehow any external work of yours hard (eg. can't go further without
>>> waiting your updates). Can't we just open a branch on svn and start to
>>> work on it. Which would also allow us to wait for fdmanana merge of
>>> new replicator
>>>
>>
>> You are free to attempt that. I on the other hand want no part of
>> having to deal with rebasing that set of patches using SVN's merge. On
>> the other hand, if we did this as a git repository we'd lose the
>> history for the entire source tree which would be even worse.
>>
>>> Related notes from my experiences and reads of the night:
>>>
>>> There are other needed changes imo:
>>>
>>> - =A0removing call go http layer in core ( for example in attachments),
>>
>> These patches don't fix everything. I very explicitly wanted to
>> minimize the scope of these patches to solely moving files around and
>> then fixing anything that broke. After these land in trunk there's
>> still going to be a lot of work left on fixing other aspects of the
>> code.
>>
>>> - having a CouchDB app that reconciliate. core (b-tree, changes, db
>>> api) and other members. Such things.
>>>
>>
>> I'm not sure what you mean by reconciling the various apps. As I
>> mention above, there's a lot to do. By no means am I suggesting this
>> patch is comprehensive. Just enough to get over the large hurdle of
>> refactoring the pathnames for files in the source tree.
>>
>>> I would be happy to work and the work in srcmv is already 70-80% of
>>> what we ant. So is there any possibility to have a branch?
>>>
>>
>> I am very scared of SVN's merging. There are nightmares involved. I
>> can barely manage to backport patches from trunk. I'm so anti-SVN I'm
>> working with infra to try and start us using Git. SVN is the devil.
>>
>> That said, if you think you'd be all right handling such a large
>> branch and the merge back to trunk after the replicator lands then by
>> all means feel free to start one. I just chose not to.
>>
>> HTH,
>> Paul Davis
>>
>
> Well at one point we should merge, whatever is the solution. Do we
> really want final tests are done in trunk ?
>

How do you mean final tests?

> I think there are way to merge from git to svn too. My point is that
> right now, we can't work on a branch , just test. And the more code
> will be added to the trunk the more it become difficult to merge too.
>

I have no idea how git-svn would handle pushing such a large move up
to SVN. Perhaps it'd work magically but I didn't feel like setting up
the infrastructure to go through and test it to make sure that we're
not dropping our entire repository history.

As to rebasing this patch set, its fairly trivial if a bit boring.

> - beno=EEt
>