On Mar 19, 2013, at 18:02 , Noah Slater <[email protected]> wrote: > 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.
The problem isn’t that we can’t have them, but that coordinating change sets that span repos is a pain in the neck. Cheers Jan -- > > > 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
