On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: >> On Saturday, December 4, 2010, Paul Davis <paul.joseph.da...@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 ? 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
