What's the issue with just creating a second Git repos? Like I did for couchdb-admin. I'd say this was a cheap operation. Doesn't cost us anything to have 3, 4, 5 repos if we need them.
I don't want to open a can of worms here. I'm not heavily invested in this. But if we avoided it because it seemed like it wasn't technically possible, then we might want to re-consider. Repos are easy to request. On 18 March 2013 23:19, Stephen Bartell <[email protected]> wrote: > > On Mar 18, 2013, at 3:49 PM, Jan Lehnardt <[email protected]> wrote: > > > > > On Mar 18, 2013, at 23:42 , Stephen Bartell <[email protected]> wrote: > > > >> Thanks guys for clearing that up. > >> > >> I work mostly in multi git setups, so naturally flags were going up > over this. The reasons make sense though. > > > > Just out of curiousity, what do you do to mitigate the pain? :) > > tl;dr version: > private npm + independent release cycles > > long version: > We've got upwards of 50 repos for project I work on. It was a complete > bitch to release. We considered moving to a single repo setup. But, we > really wanted to keep each component in its own repo. So I wrote a script > which consumed cfg file specifying what was to be included in a given > release. It would then checkout the code as prescribed and build a tar > ball. That made it waaaay easier to create a release. > > About six months ago we decided to put each component on its own release > cycle. We needed a package manager,and chose to use npm. We set up an > internal, private npm registry. Everything gets released there. Each > package defines all its dependencies and the repo from whence it came. > > I know some people would keel over at this sort of thing. But it was a > paradigm shift in how we release, maintain, and deploy our product. :) > > > > > > > Jan > > -- > > > >> > >> > >> On Mar 18, 2013, at 3:15 PM, Russell Branca <[email protected]> > wrote: > >> > >>> Hi Stephen, > >>> > >>> > >>> There was a fair bit of discussion behind this, and single repo ASF is > the > >>> real blocker. Also, while Fauxton can run as a couchapp, by default it > >>> builds down into static files and is hosted by CouchDB the same way as > >>> Futon. > >>> > >>> That said, making Fauxton as easily to develop as possible for new > >>> contributors has been a primary concern of ours. We've gotten all > >>> dependencies moved into package.json, and Garren has been knocking out > a > >>> new development server which will allow you to develop locally and not > have > >>> to build CouchDB as a part of Fauxton development. The new process will > >>> basicaly be: > >>> > >>> git clone couchdb > >>> cd couchdb/src/fauxton > >>> npm install > >>> ./bin/dev-server > >>> > >>> And you'll be up and running. > >>> > >>> > >>> -Russell > >>> > >>> > >>> On Mon, Mar 18, 2013 at 3:06 PM, Stephen Bartell <[email protected] > >wrote: > >>> > >>>> Referencing the topic [Merging the fauxton branch into master] > >>>> > >>>> Im just wondering, why can't fauxton development take place in an > entirely > >>>> separate repo from couch. Its a couch app after all, correct? > >>>> > >>>> I think fauxton could be an example of couch's modular design. > >>>> > >>>> As I write this email, I think I've realized a blocker to this idea. > And > >>>> that is that Couch really lives in a single ASF repo. Nonetheless, I > want > >>>> to throw this out there. > >>>> > >>>> Best, > >>>> Stephen Bartell > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >> > > > > -- NS
