Re: splitting rcouch in multiple repo
On Thu, Feb 6, 2014 at 6:44 PM, Paul Davis wrote: > I've managed to split out the following rcouch applications: > > couch_index > couch_mrview > couch_replicator > couch_collate > couch_httpd > couch > > And I've pushed them to their respective repositories on branches > named import-rcouch. > > This is the procedure I used to do the extract: > > https://gist.github.com/davisp/8848265 > > Hooray merges! Thanks! In your paste I don't see the procedure you followed for the couch application. Did you do anything special? - benoit
Re: can fauxton commit be tagged?
On Wed, Jan 29, 2014 at 10:32 PM, Sue wrote: > I'm fine with tagging my commits. thanks. By tagging I meant adding smth like fauxton: in the commit line ;) - benoit > > > On Wed, Jan 29, 2014 at 4:31 PM, Simon Metson wrote: > >> > > Seems awfully complicated to make fauxton erlang shaped when we >> > > already have the simple static file handler. >> > >> > depends if fauxton eed more in the future. but for now I agree. Not sure >> > though how the final build could be done for the release? sub-modules? or >> > just a curl fetch and that's all? >> >> >> Assuming eed == need - I can't see how it would need more, it's a consumer >> of the API not an API itself. If there was something it needed it would be >> built in the appropriate piece of CouchDB and Fauxton would reflect the new >> API's. >> >> So, the question remains; what needs to be done to move fauxton to the new >> repo? IIUC these new repos aren't ready for consumption, yet. Is that right? >>
Re: can fauxton commit be tagged?
On Wed, Jan 29, 2014 at 10:31 PM, Simon Metson wrote: >> > Seems awfully complicated to make fauxton erlang shaped when we >> > already have the simple static file handler. >> >> depends if fauxton eed more in the future. but for now I agree. Not sure >> though how the final build could be done for the release? sub-modules? or >> just a curl fetch and that's all? > > > Assuming eed == need - I can't see how it would need more, it's a consumer of > the API not an API itself. If there was something it needed it would be built > in the appropriate piece of CouchDB and Fauxton would reflect the new API's. > > So, the question remains; what needs to be done to move fauxton to the new > repo? IIUC these new repos aren't ready for consumption, yet. Is that right? Forgot to answer. Since then, things moved faster and Paul has splitted all repos and created the multirepo branch of bigcouch. I will do the same for rcouch in the morning. imo putting fauxton in couchdb-fauxton with a simple Makefile would be enough if you don't need any specific handler. The repo already exists (couchdb-fauxton). Would be cool if you could add the current code to it :) - benoit
[jira] [Issue Comment Deleted] (COUCHDB-2055) Continuous and EventSource are slower with filter than Longpolling
[ https://issues.apache.org/jira/browse/COUCHDB-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olafur Arason updated COUCHDB-2055: --- Comment: was deleted (was: This also affects continuous) > Continuous and EventSource are slower with filter than Longpolling > -- > > Key: COUCHDB-2055 > URL: https://issues.apache.org/jira/browse/COUCHDB-2055 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: HTTP Interface >Affects Versions: 1.4.0, 1.5.0 >Reporter: Olafur Arason > Labels: changes, filter, view > > Hi I have CouchDB 1.5, this is also a problem with 1.4 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (COUCHDB-2055) Continuous and EventSource are slower with filter than Longpolling
[ https://issues.apache.org/jira/browse/COUCHDB-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olafur Arason updated COUCHDB-2055: --- Affects Version/s: 1.4.0 1.5.0 Skill Level: Committers Level (Medium to Hard) Labels: changes filter view (was: ) Summary: Continuous and EventSource are slower with filter than Longpolling (was: Eventsource with filter is a lot slower than longpoll) > Continuous and EventSource are slower with filter than Longpolling > -- > > Key: COUCHDB-2055 > URL: https://issues.apache.org/jira/browse/COUCHDB-2055 > Project: CouchDB > Issue Type: Bug > Security Level: public(Regular issues) > Components: HTTP Interface >Affects Versions: 1.4.0, 1.5.0 >Reporter: Olafur Arason > Labels: changes, filter, view > > Hi I have CouchDB 1.5, this is also a problem with 1.4 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
