GitHub Old PR

[Frédéric Audon]

Hello,
I work to improve CBLIS. I think it is useless to submit the code via PR. You have so much to change the code since the publication of PR that it becomes impossible to merge the code. I think you should remove the olds PR because it's ridiculous to spend time on it.
I am disappointed with the way you work.

F. Audon aka Manu Troquet on GitHub

[Jens Alfke]

On Feb 18, 2015, at 5:38 PM, Frédéric Audon <Manu.T...@gmx.fr> wrote:

Hello,
I work to improve CBLIS. I think it is useless to submit the code via PR.

I think you’re referring to #409 and #546? These are several months old.

You have so much to change the code since the publication of PR that it becomes impossible to merge the code. I think you should remove the olds PR because it's ridiculous to spend time on it.

If patches stay unmerged for months they do tend to become difficult to update. That’s just part of life in a multi-person team. Some personal examples: I spent about nine months working on the ForestDB support in a branch and doing a series of increasingly nasty merges (of dozens of files) from the master branch every month or two. And I did another really difficult merge last week of some db-encryption code I’d put together last August and not updated since then.

I am disappointed with the way you work.

You’re disappointed that we’re changing the code? I don’t understand. Pasin’s been doing some great work on CBLIncrementalStore, including bug-fixing and taking advantage of the new CBLQueryBuilder.

—Jens

[Pasin Suriyentrakorn]

Hello F. Audon,

I'm sorry to hear that my recent change to CBLIncrementalStore cause some difficulty to merge on your side.

I would like to clarify that we didn't ignore your PR, and recently I did spend time study your PR and the related subjects to your PR (See #526). As your PR is a feature enhancement to the CBLIncrementalStore, we couldn't just review and merge the code like any other normal bug fix PRs. We would need a proper review whether we would like to include the feature into the product or not.

-- Pasin

[Frédéric Audon]

Hello Pasin et Jens,

Upon reflection, I think we do not have the same vision on CBLIS.

To describe the difference very quickly, below is an example.

In CoreData you an invoice headers table and another table with invoice lines.

An invoice with 2 lines.

Your CBLIS will create a doc for the invoice header and 2 docs for each invoice line.

My CBLIS will create a single doc.

We will lose our time if I offer PR with my vision and generate human tensions.

- Frédéric

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/ae8d0d98-e435-4ce2-9b17-f941d0dc9e8e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jens Alfke]

Hi Frédéric,

That’s fine if you don’t think it should be implemented the same way that we do. But a quick explanation of why we’re doing it our way:

An invoice with 2 lines.

Your CBLIS will create a doc for the invoice header and 2 docs for each invoice line.

My CBLIS will create a single doc.

For a local single-user system your way would be more efficient. However, in a distributed system, especially with the possibility of multiple users editing documents, putting everything in one doc greatly increases the chances of conflicts. Also, any change to a document requires the entire doc to be transferred by the replicator, which is less efficient than transferring a smaller doc.

—Jens