On Sun, Dec 26, 2010 at 6:39 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Mon, Dec 27, 2010 at 12:13 AM, Paul Davis > <paul.joseph.da...@gmail.com> wrote: >> On Sun, Dec 26, 2010 at 6:09 PM, Randall Leeds <randall.le...@gmail.com> >> wrote: >>> On Dec 26, 2010 6:02 PM, "Paul Davis" <paul.joseph.da...@gmail.com> wrote: >>>> >>>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bchesn...@gmail.com> >>> wrote: >>>> > 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 ? >>>> > >>>> >>>> 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? >>> >> >> The question is about how git-svn would handle a rename. If its a >> rm+add then its a non-starter. But this is exactly what I didn't want >> to configure to study the details. When does a git rename get >> translated to an svn rename, and what are the rules there. >> >>>> > - benoît >>>> > >>> >> > > didn't test but apparently there is the option -rmdir that you can > pass to dcommit with git-svn > > so using git mv ... then git dcommit -rmdir .. may works. Need to > test. Can you make available your changes on github? I will try with a > svnsync then git later this morning. > > - benoît >
The code to prepare these changes can be found here: https://github.com/davisp/couchdb-srcmv
