incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Source tree refactoring - TESTERS NEEDED
Date Sun, 26 Dec 2010 23:53:40 GMT
On Sun, Dec 26, 2010 at 6:39 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 12:13 AM, Paul Davis
> <paul.joseph.davis@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 6:09 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
>>> On Dec 26, 2010 6:02 PM, "Paul Davis" <paul.joseph.davis@gmail.com> wrote:
>>>>
>>>> On Sun, Dec 26, 2010 at 5:46 PM, Benoit Chesneau <bchesneau@gmail.com>
>>> wrote:
>>>> > On Sun, Dec 26, 2010 at 5:30 PM, Paul Davis <paul.joseph.davis@gmail.com>
>>> wrote:
>>>> >> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bchesneau@gmail.com>
>>> wrote:
>>>> >>> On Saturday, December 4, 2010, Paul Davis <paul.joseph.davis@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

Mime
View raw message