On Sun, Dec 26, 2010 at 6:32 PM, Benoit Chesneau <[email protected]> wrote: > On Mon, Dec 27, 2010 at 12:01 AM, Paul Davis > <[email protected]> wrote: >> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <[email protected]> wrote: >>> On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <[email protected]> >>> wrote: >>>> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <[email protected]> >>>> wrote: >>>>> On Saturday, December 4, 2010, Paul Davis <[email protected]> >>>>> 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.
