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 code layout
Date Thu, 01 Nov 2012 08:26:38 GMT
about multiple repo noah pointed yesterday on the cordova projet:

https://git-wip-us.apache.org/repos/asf?s=cordova

Not sure how each projects are considered though.

- benoƮt


On Thu, Nov 1, 2012 at 7:19 AM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> On Wed, Oct 31, 2012 at 9:02 PM, Adam Kocoloski <kocolosk@apache.org>
> wrote:
> > Hi, I mentioned in IRC earlier today that I'd really like to see us
> organize our source code so that OTP applications are wholly contained in
> their own subdirectories and are organized according to the standard OTP
> application layout.  In a world where we've refactored the monolithic
> 'couch' application into a few more focused applications the layout could
> look something like this:
> >
> > src/
> >         couch_core/
> >                 c_src/
> >                 include/
> >                 priv/
> >                 src/
> >                 test/
> >         couch_config/
> >                 src/
> >         ...
> >         ibrowse/
> >                 include/
> >                 src/
> >                 test/
> >
> > We've already followed this layout for couch_index, couch_mrview and
> couch_replicator -- I'd just like to "finish the job".  A few of the
> advantages that I see are
> >
> > a) We can extract these individual applications using e.g. git-subtree
> and use them on their own as we see fit.
> >
>
> I'd be fairly interested in seeing how git subtree works in real life.
> I've seen two rough uses of it. First, to include a project whole sale
> as a dependency. Ie, avoid requiring the build system to have to
> download a tarball and script that project's build system. The other
> is to do what you're suggesting where we manage them with subtree
> while their development history is tied more directly to the main
> project. I guess that's a really long winded way of "are we or are we
> not sending patches upstream as often as committing to master".
>
> For the "coordinated development" model which would require us to have
> multiple git repos for individual OTP apps we'll have to figure out if
> infra has relaxed their requirements on multiple git repos per TLP.
>
> > b) We can remove the external dependencies (ibrowse, mochiweb) from our
> git repository and instead have the build system check them out directly
> from upstream.  Of course they'd still show up directly in the release
> artefacts.
> >
>
> This we actually can't do directly. We theoretically could have ASF
> mirrors like is common practice on GitHub (ie, fork a copy to own) but
> this comes with the caveats about multiple repos from A as well as
> probably blow back on why we're simply mirroring dependency projects.
>
> > c) Rebar is the de facto build system for most other Erlang/OTP projects
> and it expects to see this kind of layout.
> >
>
> While true, we should remember that we still haven't figured out a
> plan on how to actually use rebar with Autotools. Though I don't think
> this in anyway is an argument against splitting apps. I think its
> already pretty obvious that our code organization is terrible and we
> should be doing the source tree refactoring regardless. Just wanted to
> make a note.
>
> > If there are no objections we can set about achieving this after we
> branch 1.3.x.  Regards,
> >
> > Adam
>

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