couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Source tree refactoring - TESTERS NEEDED
Date Sun, 26 Dec 2010 23:09:56 GMT
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?

> > - benoƮt
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message