couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Source tree refactoring - TESTERS NEEDED
Date Sun, 26 Dec 2010 23:39:23 GMT
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

Mime
View raw message