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: Source tree refactoring - TESTERS NEEDED
Date Sun, 26 Dec 2010 23:53:05 GMT
On Sun, Dec 26, 2010 at 6:32 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:01 AM, Paul Davis
> <paul.joseph.davis@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>> 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:
>>>>>>
>>>>>>     $ git clone git://github.com/davisp/couchdb-srcmv.git
>>>>>>     $ cd couchdb-srcmv
>>>>>>     $ ./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:
>>>>>
>>>>> -  removing 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?
>>
>
> For such a big changes, I can't imagine we do it directly in trunk. In
> my opinion it should live in a branch while we improve it?
>
> Also related question, if we split couch into modules, how  is it
> handle as an apache project?
>
> - benoît
>

Its not being done in trunk. The change is being prepared as a script
and set of patches that people can test independently which people
have been doing.

I'll reiterate my point once again that there's no way that *I* am
going to do this in an SVN branch. I just don't know SVN well enough,
and worse, my limited knowledge instills a huge amount of fear at
attempting such a feat. If there's someone that's more knowledgeable
with SVN than me that wants to drive this project, I would happily
turn it over to them.

I reckon it'll be handled exactly the same as any of the Java projects
that contain multiple packages, as in, absolutely nothing changes.

Mime
View raw message