Version control, collaborative editing and undo
incidentalcomplexity.com
Version control, collaborative editing and undo
1–10 of 32 posts
Re: Version control, collaborative editing and undo
#2Re: Version control, collaborative editing and undo
#3What are these guys building?
Re: Version control, collaborative editing and undo
#4Reminds 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?
Re: Version control, collaborative editing and undo
#5What are these guys building?
Re: Version control, collaborative editing and undo
#6What are these guys building?
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?"
Re: Version control, collaborative editing and undo
#7Re: Version control, collaborative editing and undo
#8What are these guys building?
From http://incidentalcomplexity.com/hiring/ and http://www.chris-granger.com/2014/10/01/beyond-light-table/ it sounds like the people behind Light Table are now working on an Excel-like collaborative programming environment called Eve.
Re: Version control, collaborative editing and undo
#9> 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?
http://programmers.stackexchange.com/questions/129543/what-i...
http://git-scm.com/book/en/v2/Getting-Started-About-Version-...
..not bad
Re: Version control, collaborative editing and undo
#10 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 :)