Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.213.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=WhC2VeLq5t+JSFomMZj2/bMjRg6H5tV4wORabTvrx/5nbX9Pm5sc1h9OE8aHG81IvD
         +AElrnftdNAkbWC2poE39l+3i4u9+fUOKrRFe4KePZXbG+w7Z4sAFjkqVBKs8ePkA2R8
         +yiLSYZDXHUoVYJSmlin1+edLjmpo/nZNrJ1o=
MIME-Version: 1.0
In-Reply-To: <AANLkTimxV-Yopc7BGEary4amADNeMykOz5Myu3LuKOrZ@mail.gmail.com>
References: <AANLkTikQ1XjHC94x8JuF7HFeEhjrQLBSCBgd_9B-SuZG@mail.gmail.com>
 <AANLkTimhCw=d_6ed7R9uq5OKM0tUGrXema=qJeisDGQJ@mail.gmail.com>
 <AANLkTinYRXaPGW7PjLgP9Zjb6WZw3rv6S=zC20jL_Tf7@mail.gmail.com>
 <AANLkTi=2qZNJV=P7TmrW+d2JkDSZW9FUPv0MNxvRN_vq@mail.gmail.com>
 <AANLkTi=9cP6CR346qfG2KtbxhcgdsgcJwWHyjpd1tVzL@mail.gmail.com>
 <AANLkTimxV-Yopc7BGEary4amADNeMykOz5Myu3LuKOrZ@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Sun, 26 Dec 2010 18:13:21 -0500
Message-ID: <AANLkTinkNCqZu6SWYU26cRd+bEmudf6=b3Zjv4UcPOim@mail.gmail.com>
Subject: Re: Source tree refactoring - TESTERS NEEDED
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 26, 2010 at 6:09 PM, Randall Leeds <randall.leeds@gmail.com> wr=
ote:
> 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.c=
om>
> wrote:
>> >> On Sat, Dec 25, 2010 at 10:37 PM, Benoit Chesneau <bchesneau@gmail.co=
m>
> wrote:
>> >>> On Saturday, December 4, 2010, Paul Davis <paul.joseph.davis@gmail.c=
om>
> 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 mo=
ve
>> >>>> so I'd like at least a couple other people to test this. If you hav=
e
> 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:
>> >>>>
>> >>>> =A0 =A0 $ git clone git://github.com/davisp/couchdb-srcmv.git
>> >>>> =A0 =A0 $ cd couchdb-srcmv
>> >>>> =A0 =A0 $ ./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 th=
e
>> >>>> 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 h=
as
>> >>>> as long as possible to sit in trunk before we cut 1.2.x. Let me kno=
w
>> >>>> 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 compare=
d
>> >>> to having a branch dedicated to this refactoring. Also it stops
>> >>> somehow any external work of yours hard (eg. can't go further withou=
t
>> >>> 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. O=
n
>> >> 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:
>> >>>
>> >>> - =A0removing call go http layer in core ( for example in attachment=
s),
>> >>
>> >> 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 s=
vn
> 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=EEt
>> >
>