Hey Dropbox, why can't I compare file versions like this? | Hacker News Reader

Hey Dropbox, why can't I compare file versions like this?

web.eecs.utk.edu

245 pointsazhenley130 comments

Simple: just install MS Visual SourceSafe!

In all seriousness, though, I wanted this so badly that I started (and failed) a startup with 12 employees nine years ago to build it. It was conceived for use in working with "big data" but the system essentially provided Etherpad-like scrubbable versioning of all common office document formats as a side-effect. All of it was structured in an environment more similar to the social aspects of Github than Dropbox, but you could sync up to your filesystem via a FUSE wrapper. That is, people could easily follow or fork your work in progress. If we'd continued, you'd have been able to accept the equivalent of PRs on your Word docs.

It was so awesome that we couldn't find anyone to pay for it, sadly. Armchair quarterbacks would fairly accuse us of failing to do proper customer development.

I can't speak to the technical limitations of Dropbox's versioning implementation, but given that they already have both viewing AND versioning running for a decade, I honestly can't believe it would take more than a few months for a small team to implement Etherpad-like editing functionality for the office suite document formats.

Open source it (if that's possible), let's figure out if there is community who would see value in it!

Sadly, impossible.

Could you explain why (just out of curiosity)?

Just going to go out on a limb and say the IP is owned by an investor. Paying 12 people isn't cheap, so that's why I assume there was an investor involved.

Yes, all of the above. It's quite simply not mine to open source.

If it was mine, people dramatically underestimate the effort and cost of supporting the OSS release of something like this.

It was also written on what I'm guessing was Rails 3.2 (circa 2011). There was no Docker, no Kubernetes; it was a monolith with many moving parts.

I also don't have access to the source code anymore, not easily.

It's also true that the company that we started continues to exist with a new product, and I suspect that some of our original code lives on.

It's just super messy.

Thanks for elaborating

That sounds pretty cool, though I'd have to think about how such a thing would function with the workflow of my team. I think it could be done though! It sounds like a more reliable way to do shared work on office docs.

I see some issues with it. No matter how smooth you make this, any software with pull requests is going to be considered "technical". Christ, people think basic excel skills are "technical". SO you have to get over that hurdle. But personally, if I've already gotten people over that hurdle, I might as well just use git and LaTeX documents.

I don't know, I think it sounds awesome, but I also think it might be tough to sell.

We tried to attack the market with a Github model: share your open source data and docs publicly (our true passion) and pay to have private repos.

Our mistake, as I said elsewhere, is that there was no market. We had many sales conversations and zero takers. For context, we were fully under the spell of The Great Big Data Hype of 2011 (see the current AI hype for reference) and convinced ourselves that there would be so many opportunities that we'd have our pick of which path to take.

In fairness to our past selves, for a while this seemed true; valuations were insane for companies with vague value props in the space. And we met with dozens of influencers in the data world and they all professed to be excited to use it. Most of them ultimately logged in once, realized they had no hair-on-fire problem for us to solve, and stopped returning our emails. It was frustrating in the extreme.

I just found one of our product videos on Youtube: https://www.youtube.com/watch?v=EWMjQhhxhQ4

Also, we actually did make everything available via git alongside the web frontend, API access, downloadable formats and even a beta Google Docs live connection integration. We had it set up so that you could hit save in Excel and it would commit a new version for everyone following it to access.

git wasn't yet supporting large binary commits very well (not that it's amazing support today) but I remember us going very deep on this python library that fudged support for large binary repos with the glorified equivalent of symlinks. I'm not sure we ever really got this working well and my memory is honestly fuzzy enough that it's getting harder to sort what we did from what I desperately wanted to do before we ran out of cash and I got depressed enough to take two years off and run away to Europe with a crazy person.

Humans are funny.

> but you could sync up to your filesystem via a FUSE wrapper. ... follow or fork ... accept the equivalent of PRs on your Word docs

> It was so awesome that we couldn't find anyone to pay for it, sadly. Armchair quarterbacks would fairly accuse us of failing to do proper customer development.

I get the impression that it was extremely complicated and didn't fit into anyone's workflow. IE, if you approached someone using Dropbox, they'd have to change far too many habits just to switch to you.

It was partially this, although Dropbox was not nearly as entrenched in 2011 as it is today... which by extension means that cloud storage was not a given like it is today.

It's actually far more appropriate to say that we were competing with a culture where it's engrained in people to make those FINAL_FINAL2 versions on Samba shares. Or worse, to email them.

I am biased but I'd give our UX a 7.5/10, and if we'd have continued it would have gotten smoother. The FUSE wrapper was not the primary interface by a long shot, though... in fact, I'm not sure it was used by many people outside of our team, in the end.

Dropbox has Etherpad-like functionality in its lesser known Dropbox paper product (which I find superior to Google Docs).

The irony here, is that Drew jokes about how Dropbox is going to solve these ridiculous file name versioning convention with their product in their famous YC application:

> Please tell us something surprising or amusing that one of you has discovered. (The answer need not be related to your project.)

> The ridiculous things people name their documents to do versioning, like "proposal v2 good revised NEW 11-15-06.doc", continue to crack me up.

https://www.ycombinator.com/apply/dropbox

And yet here we are a decade and change later and Dropbox, while having solved "a" problem, sits like a ridiculous behemoth leaving it's users hungry for so many other pain points to be addressed by another savior, including especially this one problem they said they're gonna solve.

Dropbox still hasn't solved many of its core issues but it has been investing in Paper (which I personally have never seen anyone using) and all that design crap from a couple of years ago.

I introduced a lot of people to Dropbox like 8-9 years ago and after using it to share files with other people I found out the hard way it's a terrible tool for that. I then used it for a couple more years to share files between my machines but they haven been introducing so much crap in their desktop app that I moved to sync.com.

Former dbx employee here— they always wanted to do it but it is technically challenging to build a fully functional product here accounting for things like formatting/comments/etc. when you have such a large enterprise user base there are often trade offs - ship a basic prototype and risk customer confusion/complaints or invest lots of resources and draw away from other projects

This is such a non-argument. They could've easily just started with text-diffs, then photo diffs. And later do doc diffs. Perhaps with some disclaimers. Heck, they don't do that for their main product, so why would they even do that for such a product. It's probably in the terms somewhere.

The reason they're not doing it is because they want a piece of the productivity pie.

They're not getting it from me. Ever.

It is challenging, very much so, but it can can be done. I built a prototype for Word files based on Git (can also use the GitHub API, so making it work with the Dropbox API should be doable). I implemented sort of a blame function as well: Jump to the previous version of a paragraph with just one click.

As OP said, it took a lot of effort to get the UI ok. Probably takes even more effort to create a great UI, but I guess Dropbox has some resources, right? Shameless plug: Landing page at https://julesdocs.com

If anyone is interested in pushing this forward, I'd love to hear from you (mail address on the landing page)!

They could have released it to personal accounts? At the rate they have embraced and catastrophically abandoned other vastly more fundamental features (packrat? Photos?) This seems far more easier to roll out slowly. Seems more like they've lost their way.

And I will never ever forgive y'all for what you did with mailbox! (Like seriously what did they do?)

> They could have released it to personal accounts?

Enterprise customers pay more money to have more features with checkboxes in the feature matrix. Telling them they don't get a feature because their needs are too complicated is a tough sell. (something, something, opens up opportunities for low-end disruption, something, something)

Google does it all the time with GSuite. I doubt customers want buggy features. Beta testing new functionality on your free/personal user accounts before rolling it out to larger business customers is pretty standard.

At Syncplicity I built something like this in a hackathon. Right-click on a file and diff it with a different version.

Sadly, we never developed it.

But, yes, I totally agree with your rationale. This is the kind of rabbit hole that can quickly turn into a distraction.

A feature like this is VERY application specific for a lot of files since you can't just take out the rendering engine and would need to usually have a third party make the software to render to web-views, whether opensource or proprietary. It's not even as if first party software is allowed to run as server. Example, psd rendering to web. AFAIK photoshop has no server license. Pretty much all services that need to render psd files use ImageMagick afaik. I looked it up and iirc. Photoshop's own api is pretty terrible to interact with and iirc licensing for servers is weird and expensive even if available.

EDIT: This comment is almost a word salad, I need to sleep lol.

While true, as others have said it could be rolled out piece-meal. For me, for example, simple text diffing would scratch a major itch, both for text and code.

Right, but as the article points out - github already has the feature for some file formats, but it's not good enough for him because he wants it specifically for powerpoint and word.

In other words, someone wants a diff tool for Microsoft products but specifically wants Dropbox to implement it.

Serious question - does anyone want this:

  ssh user@rsync.net diff some/file .zfs/snapshot/yesterday/some/file

We can implement this later today if it sounds useful ... I was sort of surprised that 'diff' was not already a whitelisted command[1] ...

[1] https://www.rsync.net/resources/howto/remote_commands.html

Does rsync.net automatically run and name zfs snapshots?

Yes. By default, every rsync.net account has 7 daily snapshots that are created and rotated automatically - no intervention on your end is required.

You may optionally set any arbitrary schedule you like (day/week/month/quarter/year) and you simply pay for the bits on disk that those (efficient, changes only) snapshots take up. Sometimes they take up almost nothing.

My favorite part of all of this is that the snapshots are immutable, or read-only. No matter who attacks your rsync.net login or what password you lose, the snapshots cannot be destroyed by any outside action.

This allows for some interesting insurance against ransomware / Mallory ...

Am I missing something? This already exists in Google Docs. Much easier to implement when the doc is database-backed (recording every keystroke for OT) vs file-based.

The Docs versión history tooling is pretty weak, though — you have to repeatedly select a timestamp. You can’t scrub, and you can’t even click on text and get “who put this here, when?”

Yeah, the thing is, you can't do this in a file-format-agnostic way (you need to know what a Word doc or an Excel sheet is), which makes the file system layer the wrong level of abstraction to consider.

You can, as long as your files have a meaningful representation as a text file. This is a good idea anyways.

That representation is one way to encode the file-format knowledge you need.

Any other way to implement would probably also involve one common format (or a small few) behind the scenes.

The diff when database-backed is still going to be file-format specific because a text-based document will not be stored in a DB identically to a spreadsheet.

There are third party document compare tools.

Dropbox could just buy one of these companies and work on integrate the solution with its platform.

All arguments about the complexity of this feature are bogus when it has been solved several times by different vendors over the last decades.

One such tool found via DDG: https://draftable.com/compare

One thing that looks weird about Draftable is that many of the comparisons are publicly-viewable. I wonder if that’s intended? See e.g. https://www.google.com/search?q=site%3Adraftable.com+%22busi...

Trying ‘site:draftable.com "confidental"’ yields interesting results. Pretty sure it’s not intended

Word already has a diff view implementation that is pretty robust - it’s very useful for figuring out what changed across manually-versioned documents. This is in addition to classical track changes feature.

Adobe Acrobat also has a diff (including visual diff) feature that can be used to do advanced comparisons if necessary.

Granted, author’s suggestion is more user friendly and integrated.

“Word already has a diff view implementation that is pretty robust”

It does? Didn’t know that. How does one activate it?

They call it “compare”

Open a document and go to "Review" ribbon and then click "Compare...".

You can do "Combine" which is effectively a merge interface.

my solution is to use pandoc to generate the diffs. Combines the benefits of word formatting but allows me to see the changes in git. (I use it mainly for my resume)

I wrote up about it here for the curious: https://www.vivekkalyan.com/using-git-for-word

Have you seen any options take advantage of the fact that docx files are just zipped xml files? I can see the git repo ballooning if you have a few images and you commit frequently!

Diffing the contents of an Office document is not trivial. See https://news.ycombinator.com/item?id=22222667

Isn’t the track changes feature of Word sufficient? I don’t use Dropbox though so perhaps it loses that..?

Author writes:

> ...but this is useless. Timestamps??? Tell me what changed! Let me see the changes over time. Word has a change tracking feature, but my PhD in computer science isn't enough for me to figure it out.

> But but but Austin, you should be using a proper version control system! Just use Git and GitHub!

Found that aside curious, as track changes in Word is a first class versioning implementation with word processing and editors savvy, just as Git is a first class versioning implementation that's code lines and commits savvy.

Surely headspace around track changes is less "PhD" than git.

“Surely headspace around track changes is less ‘PhD’ than git.”

Have you tried track changes? :)

Track changes works if you load the correct files yourself, it doesn't put all your versions in a timeline for you. It's literally just the diff visualization part of the pie, nothing else.

I can see a company like github or dropbox developing visual versioning and promoting it to make users dependent upon it. It would be an extremely sticky feature that made it hard for users to like competing products.

Imagine how github could push for MS Office integration and become a versioning powerhouse for non-code-stuff.

But I can't see it standing as a stand-alone product that people would really pay for. It has to be part of something else.

”But I can't see it standing as a stand-alone product that people would really pay for”

IMHO, if it could be smoothly integrated to e.g. Git then there would probably quite a few companies that would pay good money for it.

Version handling is built into Office 365, and many comments here indicate it's even in the relatively crappy Google Docs, but I'm sure there's a market for pretending it isn't and selling incredibly shitty half-baked attempts as a B2B SaaS offering (this is not a sarcastic "I'm sure", I know about this market space and it disgusts me on a deep level)

I’m a lawyer who uses Word’s track changes as an integral component of my work. I haven’t seen a single meaningful improvement in that feature in 20 years. Right down to the fact that I have to open “compare...” from within a document, but then have to go hunt the same document down in the file system to set it as the original. Don’t get me started on every other reason that Word has failed to innovate on this front.

The solution is to dump Office and use text files, if you can get away with it.

What’s wild to me is that a third-party product, Workshare Compare, actually does a better job of this than Microsoft does with its own product. Workshare is used widely in the AmLaw 100.

Also a garbage product IMO. The distance from something like git to Workshare is measured in light years.

I use Workshare several times a day, every day. Most transactional attorneys do. I find it works well for its intended purpose.

Some lawtech has value added over stock Office 365 - but not often. I'm very skeptical.

Use Office 365 (i.e., save your document to onedrive or a sharepoint library) - that's where the version control takes place.

We use Office 365 at my workplace and I have found the version handling to be lacking. AFAIK it can’t diff two versions of a document in a convenient way. Another gripe I have is that it is not, AFAIK, possible to tag/name versions.

Wrong and correct, respectively (the best you get is the ability to use major/minor numbering).

I associate features like this with etherpad[0] which I was in the habit of using for years for collaborative projects.

[0]: https://etherpad.org

Or Dropbox Paper which has origins in Etherpad.

Huh, Etherpad was acquired by Google in 2009 and a fork of Etherpad, Hackpad, was acquired by Dropbox in 2014 [1]. Both projects got folded however: Etherpad into Google Wave, and Hackpad into Dropbox Paper.

[1] https://en.wikipedia.org/wiki/Hackpad

Etherpad lite is still alive: https://github.com/ether/etherpad-lite

This looks similar to redline and blackline document comparisons[1]. We do this on our site[2] where we display large financial documents that average 100 pages. Identifying what text and tables were removed, added and changed from one year to another is useful information for predicting future company earnings[3]

[1] https://en.wikipedia.org/wiki/Document_comparison

[2] https://Last10K.com/compare.gif

[3] https://www.bloomberg.com/opinion/articles/2018-05-22/10-k-c...

Update: The site in reference is https://Last10K.com

I’ afraid I don’t follow… What do you mean by “our site”? Is it a system you developed for internal use or is it a product/service you sell?

Sorry, I just updated the comment with a direct link to the site which is a freemium SaaS. The other site link is an animated gif that shows how to toggle between the redline and blackline views.

Modern MS documents files are zipped XML. To do this comparison they would need to unzip each file, run it through a rendering engine and hold it in memory, and then do version comparison. For this to be feasible you would need to use a file format that supports this sort of comparison in a way that isn't very resource intensive.

It's not that, it's not like 100% of your users will be diffing documents 100% of the time. The real reason is that office formats are super, super complex and diffing them is a hard problem, even more so for the proprietary Microsoft formats.

https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...

The "zipped XMLs" you mention are basically XML dumps of the former binary format that evolved organically from the 1980s, when resources were scarce and they had to hack together a working office solution.

This! If anyone thinks that it’s trivial to diff Microsoft’s XML formats then I urge you to please try this:

• Create a simple Excel document.

• Clone the document and change the text value of one cell.

• Unzip both .xlsx files into two different directories.

• Now launch Meld/WinMerge or similar and diff the directories.

Now tell me if you still think diffing this format is trivial.

If you just want a content-aware diff (never mind formatting), it's not actually that difficult to diff; read the stylesheet so you can understand the style refs, then parse the workbook sheets and look up style refs on demand.

(Have written streaming XLSX parser in the past.)

Cool. Someone should do that :) [1]

AFAIK there are no ready-made solutions for that so far. Would be very useful![2]

[1] It would be interesting to dive further in to this subject but personally I can’t currently find the time for that.

[2] Now that I think of it, this might be an interesting project for someone participating in Google Summer of Code. Not sure if the Git project will participate this year or not.

The proper way to diff .docx documents would be to Microsoft release a diff tool for .docx documents. If they released a three-way merge tool as well then it could be used in git too. git supports 3rd party diff and merge tools for specific file formats.

It might be a lot of work and the benefits are not super obvious for them (other than community goodwill :-) ).

They already got the functionality to diff between two documents in Word. I use it all the time to see if legal made any changes while "forgetting" track changes.

Maybe libreoffice should work on it for .odt then, together with various VCS plugins (mainly git and maybe hg). It could be an interesting differentiator feature.

Sure, it's hard to diff and merge tree data structures, but it doesn't have to be perfect. Text diffing and merging is already imperfect anyway, yet it's very useful.

It’s not something you could use from a command line but Microsoft Word already does very good dock comparisons. The feature is called “compare”.

Not sure why we would need this at a file system level. You’d need diff tools for all sorts of file type.

But for the main use case you probably don't have to diff the totality of the file, just the content.

If you would simply render each version to plain text and compare them (which is a solved problem), it would already be very useful.

That’s an interesting idea. Somehow it irks me that changes of style would be totally invisible in the diff. But it could still be useful.

Not all of them. I believe Microsoft uses a special format for Office documents in OneDrive. (These files are converted to xml when you access them with non-Microsoft software)

This is a great idea, both one drive and gdrive have a versions feature but the UI isn’t great. This is terrific UX.

It’s obvious UI on the level of pinch to zoom and mouse input. Hard to come up with but obviously the right choice once suggested.

I’d also like to add on a different note, I don’t really get why git can’t support docx, pptx, and xlsx. They’re open standards not binary blobs. Basically just zipped xml.

You can configure it to support it. Git supports configuring different diff programs for different file types. And there are tools to diff docx etc.

For Excel there is this: https://www.xltrail.com/ I haven't tried it but it looks OK.

Can you explain how to do that? I must be missing something because all I could find was merge tool support but no mechanism to tell Git globally that all files with extension "xyz" should use this specific merge tool.

According to this StackOverflow post [1], you'll need to write merge driver. I was looking at this when trying to hack git to use conflict-free replicated data types (CRDTs) as a fallback for a specific document type.

[1] https://stackoverflow.com/questions/23140240/git-how-do-i-ad...

If you write VBA in Excel, there is a free Git extension called Git XL that we maintain which is able to properly Git merge your code directly in Excel: https://github.com/xlwings/git-xl

Can I configure Git such that the merge of Haskell source code (any language will do) with base A:

    add x y = x + y

left B:

    add z y = z + y

and right C:

    add x w = x + w

succeeds without a conflict?

I don't like the example. Unless I'm missing something, all three of these are exactly equivalent, so you could accept any of them as the result of a merge.

But the problem with that idea is that two different people explicitly made a change that looks meaningless. That tells us that we're evaluating "equivalent" incorrectly, which means we don't actually have any remaining justification for picking one over another, and the conflict is hopeless without further input.

The correct merge, in my opinion would be D:

    add z w = z + w

My justification is that if you put each identifier on a separate line like this:

    fn add(
        x: i32,
        y: i32,
    ) -> i32 {
        x
        +
        y
    }

then as far as I know, Git would happily merge B and C into D.

Seems like you’d need a language-aware diff algorithm that can parse the language then diff the AST.

Now if only github desktop had built in support for those extensions/configurations.

Diffing the contents of an Office document is not trivial. See https://news.ycombinator.com/item?id=22222667

Implementing good enough .docx parsing is very very hard/tedious.

For example... .docx sometimes actually contains binary blobs...

Unzip a few MS Office documents and have a go yourself.

These files can contain binary data for embedded objects like pictures.

I have the exact same question for Git. I miss Perforce timelapse view so much. :(

Yep, I wish GitHub made it easier to do diffs between a specific commit and many other commits, like with a timeline. Would be great for visually tracking down when a change was introduced or how the code has evolved over time.

That was an inspiration for a tool I built called Yestercode [1] (though it uses undo history, not version control).

[1] http://web.eecs.utk.edu/~azh/pubs/Henley2016VLHCC_Yestercode...

They've at least improved it for release comparison: https://github.blog/changelog/2020-01-13-shortcut-to-compare...

technical but important nit: github is not git.

Shout out for UofM!

Doesn't sourcetree allow you to do this

Cloud word processors like Zoho Writer & Google Docs already have version comparison features. But this idea of a sliding time traveler for documents is very intuitive!

Also Zoho Writer has a combine feature, that lets you upload a docx and combine it with another docx - with the changes highlighted as tracked-changes. Pretty handy for comparing docx files.

https://writer.zoho.com

Google docs, at least, has version history with named versions.

I don't think I'd want a scrub bar like that though, maybe? I suppose I've never tried it.

I think you'ld probably want a tree for undo/redo... it works for git and photoshop.

Reminds me of the yesterday[1] tool from Plan 9. Pretty much what the author expects, except with textual interface rather than a slider.

OHTF Vg'f uneq gb hfr guvf pbzznaq jvgubhg fvatvat.

[1] http://man.cat-v.org/plan_9/1/yesterday

I've always wanted to be able to right-click on a file that is synced in Dropbox and either have a submenu with versions to select or an option that pops up a window with the file's version history. Without having to open the Dropbox web app.

What if it’s time to add features to the undo/redo construct as a whole? Maybe not discarding redo history when a modification is made in the past for example. Computers have improved a giant amount since undo was designed (clipboard too, for that matter). We should be redesigning these common* features to keep up with the times.

*often (not in MS Office probably) the undo buffer is managed by the OS. It’s conceivable that some rethinking could happen at the OS level.

vim 7+ keeps an ‘undo tree’ that permits this (it can also be instructed to keep it in a file to persist across sessions). It’s helpful to install a visualization extension to seek around easier (https://stackoverflow.com/questions/1088864/how-is-vims-undo...)

Wasn’t the timeline concept a core part of Google Wave? If I recall correctly you were able to scrub through the entire history of a document in a similar way.

That's the first thing that came to my mind as well. RIP Wave?

I'm still waiting for dropbox to support editing .txt files in the browser.

It supports docx, excel and whatnot. But .txt file? That's too complex.

I remember ~4 years ago, I needed to retrieve an old file, and I discovered that DropBox does write a diff-based repo, which you can restore at different points. I don't remember the details, but I needed to use some sort of CLI to access/navigate it on the host system.

In short, it is probably possible now, using what DropBox already exposes.

“DropBox does write a diff-based repo”

Are you sure? I’ve never heard about that.

me neither, any more info?

> So why isn't this built directly into Dropbox, Google Docs, and Microsoft Office?

macOS includes a built-in version history since OSX Leopard. Sadly the flashy version UI with 3D effects is not the best to find differences and many programs doesn’t use the native frameworks that bring this feature (e.g MS apps, Adobe apps)

“macOS includes a built-in version history since OSX Leopard”

I had no idea. Do you have any pointers for further reading? That would be very interesting.

Since Snow Leopard MacOS has also had a local versioned file system (separate from Time Machine) but not all apps use its API and since it auto-saves and screws up "Save As..." capability I find it annoying and usually just turn it off and pretend it doesn't exist. It's one of those features Apple added that could have been useful but since they never got the UI right, most people don't know it exists.

http://osxdaily.com/2015/06/16/revert-to-prior-version-file-...

https://blog.macsales.com/47415-auto-save-and-versions-an-of...

I believe the grandparent is referring to Time Machine. Some of its versioning features may have been integrated into iCloud storage as well (not sure).

Yes, I was referring to the file version history. Sorry I couldn’t recall if it was introduced in Leopard or Snow Leopard.

I totally agree with the comment from dreamcompiler, the file history feature is a great idea but the execution needs a lot of improvement.

The main issue to me is not the change to Save as.. behavior. To me the problem is that most of the apps didn’t adopted it. In particular cross platform apps ignore it. So you never get used to the behavior change.

The version history UI, is also too “heavy”. It has a slider to go back in time, but surrounded by a faux app window simulating traveling in time with your app state... sounds cool but is distracting and not so useful to find differences.

And yes, it works with iCloud, but only in apps that use auto save APIs: https://developer.apple.com/design/human-interface-guideline...

- The Xcode source editor has a 'Code Review' mode.

- FileMerge is a standalone diff tool inside the Xcode bundle.

I used [0] for a while when I was exploring this space and was briefly in touch with the developer.

It's pretty useful and impressive in its current state but isn't being actively developed from what I understand.

[0] https://www.revisionsapp.com/

This is a really similar idea to a Chrome extension that exists for Google Docs, Draftback: https://features.jsomers.net/how-i-reverse-engineered-google...

It's almost like people just want to use sharepoint and onedrive.

I avoided both for as long as possible, but we switched to office365 at work and the integration between the two, and teams, is pretty great tbh.

Wrike (project management software) actually does this, but it is for only text descriptions which makes it easier. Wrike also color codes changes by user.

Version History already exists in MS Word for documents that are saved in OneDrive with AutoSave.

Because dropbox is not version control (i think?)

Google Wave had this exact thing, practically to the pixel.

Google Wave was so innovative that it had to be shut down... sadly...

Yeah, one of the Big Data Lizards (Google, FB) had to close one of their services. Somehow, I don't feel sad.

Wikipedia could use something like this, too.

What I would love for wikipedia is ability to select a block of text and click "show me when this was last changed"

Reply on news.ycombinator.com