
Version control, collaborative editing and undo - jscottmiller
http://incidentalcomplexity.com/2015/04/22/version-control/
======
michaelt

      Recording changes as they happen is easier than 
      inferring them after the fact
    

That's all very well if you're trying to develop something like Google Docs,
where you can define change semantics the merge process understands, then
constrain the editors to only allow changes that follow those semantics.

But the moment a user wants to take the code out of your editor to process it
with some other tool - perhaps they want to sort that text file, or minify
that javascript, or just edit in emacs because they like the keybindings -
you're back to inferring the changes after the fact.

You'd have to build a lot of tools if you want to stop your users ever wanting
to use a tool outside your editor :)

~~~
dangoor
It seems to me that the Eve folks have already decided to make that tradeoff
though: a richer environment that is necessarily walled off at least a bit
from the traditional "it's all text" approaches.

Smalltalk didn't take over the world with that approach, but it's certainly
interesting to explore.

~~~
marssaxman
I'm not sure what makes it interesting to explore; it is hard to imagine a
more reliable way to doom a programming tool to failure.

------
d--b
Collaborative live programming is a pretty bad idea in the first place. There
is one thing that's very important that you're missing in your analysis of
"the past". All DVCS system allow the programmer to group a set of changes by
commits, which constitute a consistent block of changes.

Remove that ability by constantly recording changes, and you can no longer
control your code: no code review, no feature merging. Everything just becomes
a giant mess. A mess that's auditable, but a mess nontheless

------
boothead
Shout out to "Out of the tarpit" [1] that's referenced in the "functional-
relational" link in the article. This is a great paper that's well worth 20
minutes of your time to read!

[1]
[http://shaffner.us/cs/papers/tarpit.pdf](http://shaffner.us/cs/papers/tarpit.pdf)

~~~
skrebbel
You can read that in just 20 minutes?

~~~
boothead
Maybe 25...

Actually I read it a while ago - it must have resonated because I remember it
being shorter :-)

------
erikb
> The standard solution to any hard problem [which is] is to find someone who
> solved it already and steal their answer.

Reminds me a little of the Feynman algorithm. 1) Write your question into
google. 2) Open the first three results. 3) Copy what you find.

Does it already have a name?

~~~
IanCal
"Stacksort" is probably the right thing to bring up here. A sorting algorithm
that searches SO and copies code from there until the list is sorted.

Origin: [https://xkcd.com/1185/](https://xkcd.com/1185/)

Implementation:
[http://gkoberger.github.io/stacksort/](http://gkoberger.github.io/stacksort/)

~~~
erikb
Very nice! I already forgot that one!

------
dugmartin
An alternative to OT is Differential Synchronization. You can find out more
here:

[https://neil.fraser.name/writing/sync/](https://neil.fraser.name/writing/sync/)

I wrote this to help me understand the algorithm:

[http://dougmart.in/dssimulation/](http://dougmart.in/dssimulation/)

------
zubairq
I liked the fact that the Eve guys are thinking about how git and darcs work
differently and how it affects the version history in the case of
collaborative editing.

------
grey-area
What are these guys building?

~~~
barrystaes
At first i wondered if the authors even know what they're making.. then in the
first blog post i found a mention of Light Table. It was the concept IDE with
a live preview or visualization about what parts of code output.

It appears the Eve the language evolved from that, and still is. And it seems
this DVCS (what this article is about) is meant to compliment Eve.

It made me ask the question "but what is wrong with Git? What IS the problem
Yet-Another is solving?"

------
EGreg
In the Qbix Platform ([http://platform.qbix.com](http://platform.qbix.com))
the default type of data is a Stream. A Stream is published by a User and one
or more Users can be Invited and Participate. Streams are supposed be of
different "types" and support posting Messages of different types. The
multicasting of messages to participants who are online via sockets is handled
by the pltform. Participants who are offline can maintain Subcriptions and
receive offline Notifications to their native app on a device (iOS, Android,
Mac) or email or sms or facebook. In addition there is Access control which
specifies access to the Public as well as individual users and by Labels (like
roles, but labels on contacts of the publishng User). Users can be either
people or organizations.

The whole thing is supposed to "just work" and, at version 0.8, it pretty much
does, stably. But we still have a lot to do.

The reason we chose this is because it supports everything from updating your
status / location / whatever to chatrooms and collaborative documents. A chess
game is just a stream of type "Chess/game" which supports messages like
"Chess/move" and "Chess/resign".

All the developer has to do is implement their stream type, or "tools"
(components) to interact with the stream or "preview" it in listings. We
provide typical tools such as "Streams/related" which automatically handles
showing streams related to some given stream, and can update in realtime,
allow creation of more streams, etc. The developer would jst handle incoming
messages and process their effects. Also sometimes a stream might Refresh
because the user, say, came back to a mobile app after it was suspended in the
background. In this case the stream player or preview gets the latest state
instead of "replaying" what would potentially be 100s of messages. And the
whole page doesnt need to be reloaded. It all works already.

Now we are working on Offline streams. For example, a stream that has been
created offline isn't shared with anyone so no one else can write to it. This
means we ca handle all the persistence on the client and sync it later, when
the client connects.

We do not attempt to solve issues via "heuristic" diff based sync algorithms.
Instead, the source of truth is the Publishing User's server and it is also
the source of chronological order of the messages. The developer never has to
worry about messages arriving out of order, or something else, just use the JS
API. In addition, we handle the CAP theorem by requiring consistency only per
stream. If one message contains (hashed) info from another message on some
other strean, we know it was posted later (like bitcoin).

In the end we plan to make this platform completely distributed and power
social layer for the web like wordpress powers blogs.

So that's how wedo it!

------
amelius
Does anybody know of a good Javascript implementation for a three-way merge of
JSON objects (including merging of the strings)?

