You only have eventual consistency when you use more than one instance of couch
and replication, because the write needs to be replicated to the second
instance.
You are responsible to fix conflicts yourself and CouchDB will happily tell you
where conflicts are. The way they are 'solved' the in
;
>On 19 Feb 2014, at 03:13 , Florian Westreicher Bakk.techn.
> wrote:
>
>> The patch creation is simple but the real problem is the culture.
>Review board assumes pre commit Reviews where on fact the code is
>usually already pushed, which makes the review post commit.
>
ration
>continues to improve).
>
>The 'upload patch file' approach for Review Board makes it a
>non-starter in my opinion. (Yes, we could insist every participant
>installs command lines tools to finesse that, but come on)
>
>B.
>
>On 18 Feb 2014, at 18:25, Flor
I have used review board in the past. It's easy to use but you can do most of
it on
github nowadays. Just open pull requests, others can review and comment them.
Noah Slater wrote:
>Hi folks,
>
>It's been two weeks since we got our Review Board set up. But it looks
>like nobody is using it. I
I will try to find out what is needed for a Debian build over the weekend.
Ubuntu is moving further away from the general Linux community, so a Debian
build would be nice. Also, integrating in systemd needs to be done anyway.
Lars wrote:
>It's also questionable whether you want to still suppor
No ff also preserves the knowledge that a branch was merged. I you can see the
difference when running git log --graph. When a fast forward merge is performed
it looks like all the merged commits were done directly on the current branch,
merging with no ff shows them on another branch.
Nick No
I would also not like meta data in the form of headers. AFAIK headers have a
finite length and setting them is not as straight forward as putting some json
into the request body.
Also you would have to carry over all the header information from the get
request when you update a doc or its metad
I am interested in a lot of things around CouchDB. I might try to hack
something on erica next year to learn erlang, then start grinding my teeth on
couch.
Dave Cottlehuber wrote:
>On 18. Dezember 2013 at 18:21:45, Florian Westreicher Bakk.techn.
>(st...@meredrica.org) wrote:
>&g
IMHO python is not the best idea. It would be better to extend erica since it
uses erlang.
Benjamin Young wrote:
>Hey Vivek,
>
>Thanks for open sourcing your code! I'd love to see if we can
>collaborate. Benoit passed the baton for `couchapp` on to me a few
>weeks
>back, and I'm working to du
I have no idea what that email was about, could you clarify please?
david martin wrote:
>On 02/12/13 14:16, Noah Slater wrote:
>> Thanks Benoit.
>>
>> If J Chris does not want to cede control of the domain, we might want
>> to consider using ourGoogle juice to get another website to the top
>>
How about using git notes? Messing up the commit message is a bad idea.
Jan Lehnardt wrote:
>Let’s not branch out the code just yet :)
>
>But tags are a good idea!
>
>Best
>Jan
>--
>
>On 27 Oct 2013, at 14:19 , Andy Wenk wrote:
>
>> +1 for Benoits proposal.
>>
>> Regarding "best practices" or
I'm interested, followed the thread but never posted. :-)
Noah Slater wrote:
>Okay, thanks Benoit!
>
>I agree that such things should be optional, and that if they work, we
>should look at ways of replicating their success in other areas of the
>project.
>
>The Influitive privacy policy is here:
+1
Dave Cottlehuber wrote:
>Hi folks,
>
>I got confirmation of the location, so we are go -- book your travel!
>
>Some things to consider:
>
>0. If you are going to come, please +1 this thread so I can keep track
>of people/numbers.
>
>1. If significant others want to come they are more than w
It's not yet in any release.
Vivek Pathak wrote:
>
>Hi
>
>I have found blog post indicating the merge of big couch and couchdb.
>Please tell where i can find this merged code
>
>Thanks
>Vivek
--
Sent from Kaiten Mail. Please excuse my brevity.
14 matches
Mail list logo
