codeparty/lineage

Data versioning done right.

lineage's Issues

too much documentation

Your documentation is much longer than your code.
Is there a simpler way to explain how this works?

It would probably help to see what the clock looks like as json,
initially, then what the concurrent versions look like, and then the merged version.

Also, adding methods like protocol.isConcurrent(a, b).
Would be a lot easier to read than protocol.compare(a, b) == protocol.conts.CONCURRENT
this isn't C.

If I am using this module, do I have to implement the way documents are merged?
It would be good to expand the calendar example to show merging actual data.

Vector clocks are not Lamport clocks

I realize this is likely a dead project, however there is a bit of misinformation in your README that may confuse people who are new to the subject.

That line is this:

For distributed systems, the ideal data structure to use is a vector clock, also known as a Lamport Clock.

vector clocks: when to use?

I've been thinking about when it's necessary to use vector clocks.
Vector clocks enable you do decide whether two events are concurrent (one cannot have caused the other) or causal.

It depends on how your application handles concurrency. Assuming this is used to track updates to data, then if you have two concurrent updates A,B you merge them into a third update C. so that isCausal(A, C) and isCausal(B, C).

this is a "two way merge" http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Two-way_Merge this will be unreliable if your data structure isn't commutative.
if A, B, C are concurrent merge(merge(A,B), C) MUST equal merge(merge(C,B), A). However, if our updates are commutative, do we still need vector clocks?

I'm not sure that we do, unless users perform the merges. or the merges are performed by a single authority, and not distributed. If a merge is commutative then merge(A, B) == B if isCausal(A, B).

hmm, or is the use case for vector clocks when the merge isn't commutative?

Alternatively, you could use a three way merge, but for this you need the whole histroy of changes so that you can find the common ancestor (or "concestor")

As I see it, is that vector clocks are useful when you need to keep track of events that may be concurrent, but they method for resolving concurrent changes is left unspecified by the system (as how dynamo leaves merges up to the application)

The merge doesn't necessarily need to be commutative, because you will still get eventual consistency by propagating the arbitrary merge.

I think I've answered my own question by writing this issue, what do you think?