#dat

mafintosh: i think substack has the right idea, and it might be related to the discussion seen here about whether or not to make --force default behavior when updating data https://github.com/maxogden/dat/issues/127

karissa: isn't --force default just a merge strategy though?

mafintosh: well, the idea being that we should trust the user -- any data that they're inserting into the database should be the 'new' data. older data should be versioned but retrievable

so there aren't really conflicts

does that make sense?

karissa: hmm not sure - it still sounds like a merge strategy to me. if you wanted to do something like that i guess you would have to rely on timestamps or something? (the merge strategy here being "pick the one with the highest timestamp")

mafintosh: perhaps. its just a concept, yknow. maybe timestamp isn't the necessary thing, but essentially 'order of operations' should prevail -- so new data overwrites old

karissa: i get your point :) but we can't always guarantee order of operations since we are distributed. there isn't really a single source of thruth

mafintosh: yeah, heh. maybe it'd make sense to step back a minute and get a couple examples running and see what the user experience would be like, ideally.

by 'running' i don't mean actually setting up a dat/having code, but just sketching it out

karissa: yea that might be a good idea

substack, ogd: released "stable" version of hyperlog, https://github.com/mafintosh/hyperlog

docs are still lacking but the interface should be somewhat stable now

mafintosh: mafintosh there is always a local order of operations

I think maybe just exposing which versions are the most recent prominently in the ui (the heads) would be adequate

and then just rely on the local order of operations to show the "default" view

but the need for a "default" view that "wins" is an artificial constraint imposed by the ui

i think i would prefer always showing all versions + having an explicit merge function that would combine versions to a new single version instead of having a default view

since that view would very between users

we should really be thinking about this from the perspective of a concrete example proposal that reflects a real-world situation

otherwise we will go in circles and land on the wrong target

mafintosh: yes I think that would work best

karissa: suppose you pull from mafintosh but both of you have new commits based on a common ancestor

in the couchdb/git way, the operation will fail and go into conflict resolution mode right away

in another possible way, you just see mafintosh's edits in a separate view in the ui

and you can run an explicit merge operation to combine your edits with mafintosh's edits

[dat] ajschumacher opened pull request #276: correct ESGF link (master...patch-1) http://git.io/FRdK

mafintosh: karissa melanie finnp_ call in 10 mins!

on it (finishing me demo)

great!

mafintosh: also can you put the hangout link here (not the youtube link)

https://plus.google.com/hangouts/_/hoaevent/AP3... - is this useable?

sorry, i'm not able to join you right now. looking forward to see the video later

cool stuff

we should do a write up about the multi dataset forks so substack can tell us why thats a horrible idea :)

hehe

lol

please do! :p

substack!

I was playing with node-markov this morning

small world

beep boop

my demo in the call, https://github.com/mafintosh/hyperdb