The history isnt infinite, it is stemmed by default at 1000, for the server this is reasonable, for the client not so much, its trivial to change
The history is partly to avoid conflict resolution, when you have changes to an unconnected peer you want it to be able to find the last shared parent when it reconnects otherwise it a conflict, if there was a conflict then it helps keep an audit for times when you need accurate conflict resolution If you are comfortable with the tradeoffs being made inside conflict resolution there is no need for it to be that long, and in the case of a client like pouchdb you can happily throw away history once it has successfully synced the data remotely. its something we have talked about in pouch before On 26 July 2013 21:37, Dirkjan Ochtman <[email protected]> wrote: > On Fri, Jul 26, 2013 at 8:58 PM, Andreas Gal <[email protected]> > wrote: > > The CouchDB protocol has some properties where I am not convinced that > its a > > good fit for us. Amongst others, each document has an unlimited history > that > > is tracked locally. This is actually needed for multi-party replication. > I > > would like to understand how we will deal with this. Lets say we use a > > shadow copy in couchdb. What do we do with history? This question is > > particularly important to get right, because technically speaking for a > sync > > scenario where you have 1 server that replications with many clients, but > > each of those clients only replicates with that 1 server, we don't really > > have to maintain any history in the clients to be able to replicate, if I > > understand the couchdb replication protocol correctly. With pure pouchdb > we > > would be storing that history for no reason, using up disk space beyond > the > > mere lets-store-everything-twice property of a shadow copy. > > Yes, I think the revision history is only used to help conflict > resolution, that is, to track ancestry of document revisions. If > that's not needed, you can dump the history (Apache CouchDB actually > supports this through a _purge API call). > > Cheers, > > Dirkjan > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
