On Dec 26, 2010 6:02 PM, "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? > > > 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. > > > > I have no idea how git-svn would handle pushing such a large move up > to SVN. Perhaps it'd work magically but I didn't feel like setting up > the infrastructure to go through and test it to make sure that we're > not dropping our entire repository history. > > As to rebasing this patch set, its fairly trivial if a bit boring. >
If you can rebase it so it's linear from the end of trunk you can push it up with git-svn no problem. You do the rebasing locally and then just `git svn dcommit`. Am I missing something? > > - benoît > >
