incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Source tree refactoring - TESTERS NEEDED
Date Sun, 26 Dec 2010 22:46:45 GMT
On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <> wrote:
> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <> wrote:
>> On Saturday, December 4, 2010, Paul Davis <> 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://
>>>     $ cd couchdb-srcmv
>>>     $ ./
>>> 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]
>> 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 ?

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.

- benoît

View raw message