Re: retry: query re: couchdb's use of git.
And just to clarify some points... On 22 October 2012 19:46, Dan Haywood d...@haywood-associates.co.uk wrote: Poking around your website and wiki, it does seem to me that you've managed to make GIT into your primary repo, and abandon SVN all together? We still use SVN for our website. Everything else is in Git. Two separate repositories, for two separate things. My question is: is there a process for doing this? All of the documentation in ASF at the moment seems to be related to maintaining a GIT mirror but still having SVN as the master. We definitely do not run a Git mirror of anything. We use Git directly. We have a mirror of our primary Git on Github, but that is for the convenience of Github users. By the way, Git works fine at the ASF, IMO. We have no problems that I know of. :) -- NS
Re: [IRC] dev meeting 2012-10-18
This is great, thanks Dave! I like the idea of tracking open/active actions. So we don't let them fall on the ground. :) See you all tomorrow for the meeting! On 18 October 2012 12:57, Dave Cottlehuber d...@jsonified.com wrote: Hi everybody, We had another week whizz by in IRC and real life! Thanks everybody who attended, and reminder if the time *doesn't* work for you please let us know! New Actions: - Garren Smith to send a proposal to the mailing list for futon2, check in with Alex Shorin Ryan Ramage jspec discussions to get rolled into general futon2/jquery.couch work with the above - Dirkjan Ochtman to update wiki with how do add versioning information into rst docs - Dave Cottlehuber to keep 1.2.0 updates on track, show some visible progress - Robert Newson to email or jira his thoughts on a migration tool from non-sharded couch to shared bigcouch. This may or may not require an HTTP layer - Robert Newson to think of a better name for futon.next In Progress: - Noah Slater to send out release cadence as discussed in Eire with Robert Newson - Dave Cottlehuber will go through JIRA and mark items that block 1.3 release - Wendall Cada and Joan Touzet to get stuck into packaging - Noah Slater to announce 1.3 blockers JIRA workflow, and invite contribution to final feature list - Adam Kocoloski Benoit Chesneau to send summary of testing in their forks to dev@ to start the discussion - Joan Touzet to help Wendall Cada with build system work - Adam Kocoloski to provide woolly update on how cloudant and bigcouch and couchdb fit together in the future Use the Futon if you're going to sleep: http://nexdork.com/img/9/11%5CBEA1FDA7BC42EE097C23842788B5DF6F.gif via kxepal [actions]: http://people.apache.org/~dch/couchdb-dev-irc-meetings/2012/couchdb-dev.2012-10-17-19.00.html [logs]: http://people.apache.org/~dch/couchdb-dev-irc-meetings/2012/couchdb-dev.2012-10-17-19.00.log.html [history]: http://wiki.apache.org/couchdb/IRC_Meeting_Minutes -- NS
Re: couchdb pull request: Many fixes to $.couch
Can someone take a look at this? On 16 October 2012 18:23, boxxxie g...@git.apache.org wrote: https://github.com/apache/couchdb/pull/34 -- NS
Re: [REL1.3.0] CouchDB Windows / OS X packages (Progress?)
Just following up on this. CCing Hans and Joan directly. On 14 October 2012 19:49, Noah Slater nsla...@tumbolia.org wrote: Do you think we can get this AMI ready for the 1.3 release? @Hans, do you wanna take a look at what it would take to fold your work in? I'm sure Dave or myself can answer any questions you run in to. @Joan, how long would the MSI stuff take? On Sun, Oct 14, 2012 at 7:45 PM, Dave Cottlehuber d...@jsonified.comwrote: On 14 October 2012 12:27, Noah Slater nsla...@tumbolia.org wrote: Hey, This is the first of several What's up with releasing 1.3? emails. (See subject prefix!) I wanted to start a discussion around our Windows and OS X packages. At the moment, our OS X package is hosted on Github, which we need to fix. What can we do to get this package into the source, and maybe iterate on it a little? And are there any improvements we can make to our Windows package for this release? Any volunteers to head up these efforts? Anybody who wants to help here is welcome :-) I am mid updating the public AMI I use for test builds, to include an R15B02 OTP instead of the R15B I have. That avoids the need for people to spend ages getting a dev environment set up. @Wohali has some bits to make an MSI package, better than my hacky attempts a year ago. That would be cool. I'm gonna revert to using a newer OpenSSL library if it works out in testing. Nothing else major comes to mind down here. A+ Dave -- NS -- NS
Re: retry: query re: couchdb's use of git.
Many thanks for all these answers, much appreciated. Will aim to follow your model as closely as we can.., Cheers Dan On 23 October 2012 11:19, Noah Slater nsla...@apache.org wrote: And just to clarify some points... On 22 October 2012 19:46, Dan Haywood d...@haywood-associates.co.uk wrote: Poking around your website and wiki, it does seem to me that you've managed to make GIT into your primary repo, and abandon SVN all together? We still use SVN for our website. Everything else is in Git. Two separate repositories, for two separate things. My question is: is there a process for doing this? All of the documentation in ASF at the moment seems to be related to maintaining a GIT mirror but still having SVN as the master. We definitely do not run a Git mirror of anything. We use Git directly. We have a mirror of our primary Git on Github, but that is for the convenience of Github users. By the way, Git works fine at the ASF, IMO. We have no problems that I know of. :) -- NS
Branching for the CouchDB 1.3 release
All, It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. As I understand, the principal outstanding issues blocking the 1.3.0 release are; 1) Randall Leed's backports of fixes from 1.2.0. This code is written and I have reviewed it, though more eyes are appreciated. 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. 3) The blockers marked in JIRA. I think all of those things can land on 1.3.x and master. Can I get some votes on my proposal to branch today please? B.
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: Can I get some votes on my proposal to branch today please? Yes, please! Cheers, Dirkjan
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: All, It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. As I understand, the principal outstanding issues blocking the 1.3.0 release are; 1) Randall Leed's backports of fixes from 1.2.0. This code is written and I have reviewed it, though more eyes are appreciated. 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. 3) The blockers marked in JIRA. I think all of those things can land on 1.3.x and master. Can I get some votes on my proposal to branch today please? B. -1 the branch should appear once all patches are landed. What would be the reason to branch now? - benoit
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. It will land tomorrow I have been busy to extract it from the code and to make sure it can been released. - benoit
Re: Branching for the CouchDB 1.3 release
On Oct 23, 2012, at 18:42 , Robert Newson rnew...@apache.org wrote: All, It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. As I understand, the principal outstanding issues blocking the 1.3.0 release are; 1) Randall Leed's backports of fixes from 1.2.0. This code is written and I have reviewed it, though more eyes are appreciated. 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. 3) The blockers marked in JIRA. For your convenience: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+COUCHDB+AND+priority+%3D+Blocker+AND+status+%21%3D+Resolved+AND+fixVersion+%3D+%221.3%22+ORDER+BY+key+DESC%2C+updated+DESC I think all of those things can land on 1.3.x and master. Can I get some votes on my proposal to branch today please? +1
Re: Branching for the CouchDB 1.3 release
... to get the other things out and move to the plan of regular releases we promised so many months ago. On 23 October 2012 17:51, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: All, It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. As I understand, the principal outstanding issues blocking the 1.3.0 release are; 1) Randall Leed's backports of fixes from 1.2.0. This code is written and I have reviewed it, though more eyes are appreciated. 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. 3) The blockers marked in JIRA. I think all of those things can land on 1.3.x and master. Can I get some votes on my proposal to branch today please? B. -1 the branch should appear once all patches are landed. What would be the reason to branch now? - benoit
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 6:51 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: All, It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. As I understand, the principal outstanding issues blocking the 1.3.0 release are; 1) Randall Leed's backports of fixes from 1.2.0. This code is written and I have reviewed it, though more eyes are appreciated. 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. 3) The blockers marked in JIRA. I think all of those things can land on 1.3.x and master. Can I get some votes on my proposal to branch today please? B. -1 the branch should appear once all patches are landed. What would be the reason to branch now? i mean there is no reason to branch right now. We should make sure to release when everything is frozen. If not we will continuously go from one branch to the other which could be really problematic. cf last story of 1.2. - benoit
Re: Branching for the CouchDB 1.3 release
Appreciate you are busy, and appreciate even more getting the code out tomorrow. My point remains that we should be time-based not feature-based now, it's no harm to bump to 1.4. That said, CORS in 1.3 would be awesome. On 23 October 2012 17:53, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. It will land tomorrow I have been busy to extract it from the code and to make sure it can been released. - benoit
Re: Branching for the CouchDB 1.3 release
Branching would free master for commits that are not destined to go in 1.3. The reason to branch is to get some focus and momentum around the 1.3.0 release. And it seems to be working. B. On 23 October 2012 18:01, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 6:51 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 6:42 PM, Robert Newson rnew...@apache.org wrote: All, It's been a while since we released and I want to change this now. I propose making a 1.3.x branch from today's master (66529378dd06342929e04772370f3509cbe786a5) and building 1.3.0 there. As I understand, the principal outstanding issues blocking the 1.3.0 release are; 1) Randall Leed's backports of fixes from 1.2.0. This code is written and I have reviewed it, though more eyes are appreciated. 2) The CORS patch. This has been around for a very long time but has not reached our repository in any form. Earlier this month I proposed that if it does not appear in usable form by the end of the calendar month, it gets bumped to the next release. 3) The blockers marked in JIRA. I think all of those things can land on 1.3.x and master. Can I get some votes on my proposal to branch today please? B. -1 the branch should appear once all patches are landed. What would be the reason to branch now? i mean there is no reason to branch right now. We should make sure to release when everything is frozen. If not we will continuously go from one branch to the other which could be really problematic. cf last story of 1.2. - benoit
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 7:01 PM, Robert Newson rnew...@apache.org wrote: ... to get the other things out and move to the plan of regular releases we promised so many months ago. In other worlds we do the inverse though ... - benoit
Re: couchdb pull request: Many fixes to $.couch
I took a quick peek and the code looks like the expected changes to switch jquery.couch.js to use jquery deferreds, which in my opinion, is a good addition. I haven't run the test suite with it, but assuming it doesn't break the existing callback based functionality, it would be an ubobtrusive and good feature to add. For the changes to the urlPrefix functionality, I've got a couple questions about the statement: removed the $.couch.urlPrefix, which wasn't working correctly anyway. since it wasn't working correctly i assume nobody is using it. What part of it isn't working? Currently urlPrefix allows you to specify a subdomain url for a database server as expected, and I've used it on many occasions. What the changes to urlPrefix in this pull request do appear to accomplish, is that by delaying the insertion of the base url from the initial creation of the db object [1] into the methods themselves ([2] for instance), you will then be able to set the url after you have created a db object. For instance, if you do: $.couch.urlPrefix = http://me.mydb.com; var db = $.couch.db(some_db) $.couch.urlPrefix = http://otherdb.com; In the current jquery.couch.js, urlPrefix will be hardcoded into the db variable, and further updates to $.couch.urlPrefix would not be brought in, whereas the patch would allow that to happen, which is arguablly a useful feature. My guess is that the broken functionality he was seeing was trying to set $.couch.urlPrefix after already having created a db object, which will not work. In my opinon, the name change from urlPrefix to url is an unneeded API change that will require code updates as people are currently using urlPrefix. The switch to deferreds should be unobtrusive, and keeping urlPrefix as the name will also keep the patches unobtrusive. Couple minor nits: The ajax deferred should be returned in [3]. Need to add $.couch.url in [4]. Overall looks like a good patch. I'm a big fan of jquery deferreds for ajax and they would be a welcome addition to jquery.couch.js, assuming that the test suite passes with this and the existing callbacks are unaffected. -Russell [1] https://github.com/apache/couchdb/pull/34/files#L0L284 [2] https://github.com/apache/couchdb/pull/34/files#L0R310 [3] https://github.com/apache/couchdb/pull/34/files#L0L316 [4] https://github.com/apache/couchdb/pull/34/files#L0L340 On Tue, Oct 23, 2012 at 6:24 AM, Noah Slater nsla...@apache.org wrote: Can someone take a look at this? On 16 October 2012 18:23, boxxxie g...@git.apache.org wrote: https://github.com/apache/couchdb/pull/34 -- NS
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 7:03 PM, Robert Newson rnew...@apache.org wrote: Branching would free master for commits that are not destined to go in 1.3. The reason to branch is to get some focus and momentum around the 1.3.0 release. And it seems to be working. B. Let's reformulate , why not plan for a freeze on 11/5 an da release at the end of the month or sooner? It will let time to land all patches we want in and fix latest bits. New features could go in a branch if needed. thoughts? - benoit
Re: Branching for the CouchDB 1.3 release
On Oct 23, 2012, at 19:03 , Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 7:01 PM, Robert Newson rnew...@apache.org wrote: ... to get the other things out and move to the plan of regular releases we promised so many months ago. In other worlds we do the inverse though ... There is about every permutation of this done among all the projects out there. We picked that particular one and we should just move forward until there is significant cause for course correction, which I don't see at the moment. Cheers Jan --
Re: Branching for the CouchDB 1.3 release
I'm happy to defer branching until 11/5 as long as we're clear that anything not on master by that date will not appear in the 1.3 release. After 1.3, I want us to execute on the roadmap process we discussed in Dublin (documented here: https://wiki.apache.org/couchdb/Roadmap_Process) where we release every 3 months. B. On 23 October 2012 18:40, Jan Lehnardt j...@apache.org wrote: On Oct 23, 2012, at 19:03 , Benoit Chesneau bchesn...@gmail.com wrote: On Tue, Oct 23, 2012 at 7:01 PM, Robert Newson rnew...@apache.org wrote: ... to get the other things out and move to the plan of regular releases we promised so many months ago. In other worlds we do the inverse though ... There is about every permutation of this done among all the projects out there. We picked that particular one and we should just move forward until there is significant cause for course correction, which I don't see at the moment. Cheers Jan --
Re: Branching for the CouchDB 1.3 release
On Tue, Oct 23, 2012 at 7:43 PM, Robert Newson rnew...@apache.org wrote: I'm happy to defer branching until 11/5 as long as we're clear that anything not on master by that date will not appear in the 1.3 release. agree. After 1.3, I want us to execute on the roadmap process we discussed in Dublin (documented here: https://wiki.apache.org/couchdb/Roadmap_Process) where we release every 3 months. + 1 - benoît
hackaton
Helllo all, I would like to discuss the idea of an hackaton between couchdb committer and maybe some people invited either at the end of the year of next year. The idea would be this time to focus on the code and only the code. Some projects do this on a regular basis and it generally give a lot of good resuls Topics would be for example: - bigcouch merge - OTP - HTTP refactoring But no need to choose them now. I would like to know if you would be interested. Location need to be defined too. Thoughts? Also all details can be fixed on the next meeting. - benoît
Re: couchdb pull request: Many fixes to $.couch
thks for info - not entirely sure how this will integrate with the upcoming CORS commit but when that appears, we will try to use all of it in a non-couchapp html5 program - previously we could not get things running with lots of cross-domain errors, etc. Should make for a good test and a nice how-to/tutorial to go with CORS feature whether it makes 1.3 or 1.4. On 10/23/2012 11:37 AM, Russell Branca wrote: I took a quick peek and the code looks like the expected changes to switch jquery.couch.js to use jquery deferreds, which in my opinion, is a good addition. I haven't run the test suite with it, but assuming it doesn't break the existing callback based functionality, it would be an ubobtrusive and good feature to add. For the changes to the urlPrefix functionality, I've got a couple questions about the statement: removed the $.couch.urlPrefix, which wasn't working correctly anyway. since it wasn't working correctly i assume nobody is using it. What part of it isn't working? Currently urlPrefix allows you to specify a subdomain url for a database server as expected, and I've used it on many occasions. What the changes to urlPrefix in this pull request do appear to accomplish, is that by delaying the insertion of the base url from the initial creation of the db object [1] into the methods themselves ([2] for instance), you will then be able to set the url after you have created a db object. For instance, if you do: $.couch.urlPrefix = http://me.mydb.com; var db = $.couch.db(some_db) $.couch.urlPrefix = http://otherdb.com; In the current jquery.couch.js, urlPrefix will be hardcoded into the db variable, and further updates to $.couch.urlPrefix would not be brought in, whereas the patch would allow that to happen, which is arguablly a useful feature. My guess is that the broken functionality he was seeing was trying to set $.couch.urlPrefix after already having created a db object, which will not work. In my opinon, the name change from urlPrefix to url is an unneeded API change that will require code updates as people are currently using urlPrefix. The switch to deferreds should be unobtrusive, and keeping urlPrefix as the name will also keep the patches unobtrusive. Couple minor nits: The ajax deferred should be returned in [3]. Need to add $.couch.url in [4]. Overall looks like a good patch. I'm a big fan of jquery deferreds for ajax and they would be a welcome addition to jquery.couch.js, assuming that the test suite passes with this and the existing callbacks are unaffected. -Russell [1] https://github.com/apache/couchdb/pull/34/files#L0L284 [2] https://github.com/apache/couchdb/pull/34/files#L0R310 [3] https://github.com/apache/couchdb/pull/34/files#L0L316 [4] https://github.com/apache/couchdb/pull/34/files#L0L340 On Tue, Oct 23, 2012 at 6:24 AM, Noah Slater nsla...@apache.org wrote: Can someone take a look at this? On 16 October 2012 18:23, boxxxie g...@git.apache.org wrote: https://github.com/apache/couchdb/pull/34 -- NS
[jira] [Assigned] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Newson reassigned COUCHDB-1259:
--
Assignee: Robert Newson (was: Filipe Manana)
Replication ID is not stable if local server has a dynamic port number
--
Key: COUCHDB-1259
URL: https://issues.apache.org/jira/browse/COUCHDB-1259
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Reporter: Jens Alfke
Assignee: Robert Newson
Priority: Blocker
Fix For: 1.3
Attachments: couchdb-1259.patch, couchdb-1259.patch
I noticed that when Couchbase Mobile running on iOS replicates to/from a
remote server (on iriscouch in this case), the replication has to fetch the
full _changes feed every time it starts. Filipe helped me track down the
problem -- the replication ID is coming out different every time. The reason
for this is that the local port number, which is one of the inputs to the
hash that generates the replication ID, is randomly assigned by the OS. (I.e.
it uses a port number of 0 when opening its listener socket.) This is because
there could be multiple apps using Couchbase Mobile running on the same
device and we can't have their ports colliding.
The underlying problem is that CouchDB is attempting to generate a unique ID
for a particular pair of {source, destination} databases, but it's basing it
on attributes that aren't fundamental to the database and can change, like
the hostname or port number.
One solution, proposed by Filipe and me, is to assign each database (or each
server?) a random UUID when it's created, and use that to generate
replication IDs.
Another solution, proposed by Damien, is to have CouchDB let the client work
out the replication ID on its own, and set it as a property in the
replication document (or the JSON body of a _replicate request.) This is even
more flexible and will handle tricky scenarios like full P2P replication
where there may be no low-level way to uniquely identify the remote database
being synced with.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COUCHDB-1570) Replicator writes corrupt remote checkpoint document on error; breaks revision forever
[
https://issues.apache.org/jira/browse/COUCHDB-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds reassigned COUCHDB-1570:
--
Assignee: Randall Leeds
Replicator writes corrupt remote checkpoint document on error; breaks
revision forever
--
Key: COUCHDB-1570
URL: https://issues.apache.org/jira/browse/COUCHDB-1570
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Mac OS X 10.8.2
Reporter: Jens Alfke
Assignee: Randall Leeds
Priority: Blocker
Fix For: 1.3
If a 'push' replication receives error responses from the remote server while
PUTting documents, it may write a corrupt checkpoint document to the remote
server -- its _revisions._ids property is null. Any subsequent attempt to
push to that server will cause the replicator to abort with an error when
reading that replication document, since it requires _revisions.ids to be an
array.
The only workaround for this, short of deleting the remote database entirely,
is to (a) identify the URL of the remote checkpoint document, and (b) delete
it from the remote server. Otherwise you will never be able to push to that
database again.
Here's a failed replication attempt:
$ curl -X POST --user snej :5984/_replicate --header
Content-Type:application/json --data
'{source:demo-shopping-attachments,target:http://localhost:4984/demo-shopping-attachments,create_target:true}'
{error:doc_validation,reason:_revisions.ids isn't a array.}
Here's the contents of the remote checkpoint document, once I identified its
ID:
$ curl :4984/demo-shopping-attachments/_local/5b913befe682d7bd1fbc24b1ce31cbc5
{_id:_local/5b913befe682d7bd1fbc24b1ce31cbc5,_rev:0-1,_revisions:{ids:null,start:0},history:[{doc_write_failures:2,docs_read:2,docs_written:0,end_last_seq:207,end_time:Sun,
21 Oct 2012 19:40:04
GMT,missing_checked:17,missing_found:2,recorded_seq:207,session_id:9a24dc37885b5b4e507ea90702b2fecf,start_last_seq:0,start_time:Sun,
21 Oct 2012 19:40:04
GMT}],replication_id_version:2,session_id:9a24dc37885b5b4e507ea90702b2fecf,source_last_seq:207}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1570) Replicator writes corrupt remote checkpoint document on error; breaks replication
[
https://issues.apache.org/jira/browse/COUCHDB-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Alfke updated COUCHDB-1570:
Summary: Replicator writes corrupt remote checkpoint document on error;
breaks replication (was: Replicator writes corrupt remote checkpoint document
on error; breaks revision forever)
Replicator writes corrupt remote checkpoint document on error; breaks
replication
-
Key: COUCHDB-1570
URL: https://issues.apache.org/jira/browse/COUCHDB-1570
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Mac OS X 10.8.2
Reporter: Jens Alfke
Assignee: Randall Leeds
Priority: Blocker
Fix For: 1.3
If a 'push' replication receives error responses from the remote server while
PUTting documents, it may write a corrupt checkpoint document to the remote
server -- its _revisions._ids property is null. Any subsequent attempt to
push to that server will cause the replicator to abort with an error when
reading that replication document, since it requires _revisions.ids to be an
array.
The only workaround for this, short of deleting the remote database entirely,
is to (a) identify the URL of the remote checkpoint document, and (b) delete
it from the remote server. Otherwise you will never be able to push to that
database again.
Here's a failed replication attempt:
$ curl -X POST --user snej :5984/_replicate --header
Content-Type:application/json --data
'{source:demo-shopping-attachments,target:http://localhost:4984/demo-shopping-attachments,create_target:true}'
{error:doc_validation,reason:_revisions.ids isn't a array.}
Here's the contents of the remote checkpoint document, once I identified its
ID:
$ curl :4984/demo-shopping-attachments/_local/5b913befe682d7bd1fbc24b1ce31cbc5
{_id:_local/5b913befe682d7bd1fbc24b1ce31cbc5,_rev:0-1,_revisions:{ids:null,start:0},history:[{doc_write_failures:2,docs_read:2,docs_written:0,end_last_seq:207,end_time:Sun,
21 Oct 2012 19:40:04
GMT,missing_checked:17,missing_found:2,recorded_seq:207,session_id:9a24dc37885b5b4e507ea90702b2fecf,start_last_seq:0,start_time:Sun,
21 Oct 2012 19:40:04
GMT}],replication_id_version:2,session_id:9a24dc37885b5b4e507ea90702b2fecf,source_last_seq:207}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1572) Remove support for spidermonkey versions 1.8.5
Robert Newson created COUCHDB-1572: -- Summary: Remove support for spidermonkey versions 1.8.5 Key: COUCHDB-1572 URL: https://issues.apache.org/jira/browse/COUCHDB-1572 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Simplify build system and provide a consistent Javascript environment by ditching spidermonkey versions below 1.8.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1572) Remove support for spidermonkey versions 1.8.5
[ https://issues.apache.org/jira/browse/COUCHDB-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1572: --- Fix Version/s: 1.4 Not for 1.3, doesn't need to wait for 2.0 (unless we consider this 'breaking' enough?), so I made a middle version for now, but would appreciate feedback. Remove support for spidermonkey versions 1.8.5 Key: COUCHDB-1572 URL: https://issues.apache.org/jira/browse/COUCHDB-1572 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Fix For: 1.4 Simplify build system and provide a consistent Javascript environment by ditching spidermonkey versions below 1.8.5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: hackaton
On Tue, Oct 23, 2012 at 10:57 AM, Benoit Chesneau bchesn...@gmail.com wrote: Helllo all, I would like to discuss the idea of an hackaton between couchdb committer and maybe some people invited either at the end of the year of next year. The idea would be this time to focus on the code and only the code. Some projects do this on a regular basis and it generally give a lot of good resuls Topics would be for example: - bigcouch merge - OTP - HTTP refactoring But no need to choose them now. I would like to know if you would be interested. Location need to be defined too. Thoughts? Also all details can be fixed on the next meeting. - benoît Very interested. +1 for putting it on the meeting agenda.
[jira] [Created] (COUCHDB-1573) Use JSON.stringify
Robert Newson created COUCHDB-1573: -- Summary: Use JSON.stringify Key: COUCHDB-1573 URL: https://issues.apache.org/jira/browse/COUCHDB-1573 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Fix For: 1.4 Ditch json.js and eval() calls entirely and use the native JSON.stringify/parse calls in spidermonkey. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1574) Bundle a simple design-doc/couchapp command-line tool.
Ryan Ramage created COUCHDB-1574: Summary: Bundle a simple design-doc/couchapp command-line tool. Key: COUCHDB-1574 URL: https://issues.apache.org/jira/browse/COUCHDB-1574 Project: CouchDB Issue Type: New Feature Components: Build System Reporter: Ryan Ramage Priority: Minor Fix For: 2.0 As discussed on the mailing list, having a design doc loader/couchapp tool bundled with couchdb will be beneficial. Erica would be the best fit being an erlang solution, and it supports the traditional design doc structure out of the box. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1574) Bundle a simple design-doc/couchapp command-line tool.
[ https://issues.apache.org/jira/browse/COUCHDB-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Ramage updated COUCHDB-1574: - Fix Version/s: (was: 2.0) 1.4 Bundle a simple design-doc/couchapp command-line tool. --- Key: COUCHDB-1574 URL: https://issues.apache.org/jira/browse/COUCHDB-1574 Project: CouchDB Issue Type: New Feature Components: Build System Reporter: Ryan Ramage Priority: Minor Fix For: 1.4 As discussed on the mailing list, having a design doc loader/couchapp tool bundled with couchdb will be beneficial. Erica would be the best fit being an erlang solution, and it supports the traditional design doc structure out of the box. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1573) Use JSON.stringify
[ https://issues.apache.org/jira/browse/COUCHDB-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13482939#comment-13482939 ] Joan Touzet commented on COUCHDB-1573: -- I cannot have this assigned to me (yet) but I have the patch for this for BigCouch about to be released, and will submit an appropriate CouchDB patch for this in the next week or so. Use JSON.stringify -- Key: COUCHDB-1573 URL: https://issues.apache.org/jira/browse/COUCHDB-1573 Project: CouchDB Issue Type: Improvement Reporter: Robert Newson Fix For: 1.4 Ditch json.js and eval() calls entirely and use the native JSON.stringify/parse calls in spidermonkey. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
