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 16:30:06 GMT
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

Mime
View raw message