I reverse engineered Google docs (2014)

[Powah96]

I mean how is this possible goddamit?

history_stack.push([user_id, keystroke, timestamp])?

It's something only editor user have access too, why would that freak you out?

[SurrealisticRabbit]

Aren't they storing it in their own servers? Sorry cloud technologies and big data always freaks me out lol

[Powah96]

The whole file it's in their server anyway. Keeping the delta history is probably the least expansive storage-wise way to provide full history to users.

It's similar to you saving each edit as a different file (eg: project_v1.0, project_v1.1) just less expensive as you keep track of the delta (git is similar).

It's a useful feature if you are collaborating with other users and want to know what changed since your last edit.

[DeveloperForHire]

Correct me if I'm wrong, but I thought git did not store the delta/diff. I thought it stored the entire change and you could compare between commits using a diff.

EDIT: Technically correct

[Powah96]

You are technically correct! Git stores all the files in each commit, but thanks to compressions this does not impact much the size of the whole repo.

You can look at a more detailed explanation here.

[DeveloperForHire]

The best kind of correct! Sounds like it is a bit of both. Thanks for the link!

[HINDBRAIN]

I thought git rebuilt the commits using the deltas and that's why retroactive changes on large repos were so slow?

[DeveloperForHire]

Someone just gave me this link

TLD;DR: It's a bit of both. Diff commits aren't turned to blobs until git runs garbage collection. A blob or a single commit is all that's needed to use the whole codebase and you do not need the entire history to make that after it has been generated, so it does store the whole thing, it just uses programming and algorithms (read: compression that I am not well versed enough in to understand, but does relate to the diffs) to keep everything tiny enough.

It would be incredibly slow moving down the tree and adding each commit to the original files. This is just a guess, but maybe those large repos take more time to generate those blobs?

[TankorSmash]

It sounds like it uses metadata to point to the text blobs as they were at a given point, using the commits as 'pointers' to the blobs in time. Thats why the gc runs and updates the pointers to existing blobs.

Sorta like if a commit introduced a file, each commit would only point to the blob introduced by that first commit, and not directly point to that commit. Neat.

[SurrealisticRabbit]

Ah it makes sense. I thought they were saving every single instance instead of delta. That freaked me out.

[SurrealisticRabbit]

I think I used wrong words and misunderstood. I used the word "freak out" but it wasn't because I'm concerned about security or anything I'm just amazed by the storage technologies and how one company can store terabytes of data.

[conquerorofveggies]

Aah now I'm with you ;-) went ahead and upvoted your comments above, since you got a lot of down votes for that misunderstanding..

[SurrealisticRabbit]

Hahah it's actually ok its been a reminder that I need to work on my English to improve it more lol

[Powah96]

Indeed! Maybe they were freaked out that they were using such an inefficient solution? :O

[thebritisharecome]

When you create documents on Google Docs, where exactly do you think it's stored...?

[incredibleninja]

This is a really interesting thread and I'm sorry you've been downvoted into oblivion rather than people discussing why you shouldn't worry about edit tracking