Hacker News Reader

Comment by TomOfTTB | Hacker News Reader

binary comparisons are great if you aren't looking at shared files but once you get into a situation where two different people can be editing a file at the same time it really helps to know what data you're dealing with rather than just trying to do a straight binary comparison.

You could very well be right about what they're planning but if that's the way they're going it will end up killing them in the end. As someone who administers Dropbox in a team environment the biggest issue is its creation of "Copy" files whenever there are simultaneous edits.

I mean, think about it. If you're using Photoshop and your edits go into a copy file you basically have to re-do that work. There's no easy way to merge changes (I guess if you were working on different layers but still it's difficult).

View on HN

Simultaneous editing isn't a problem Dropbox is meant to solve, or is realistically able to solve given the proliferation of document formats out there. For stuff like PSDs, collaborative editing really needs to be baked into the software (and by extension, the document format). For textual data, DVCS works well.

How is it not realistic to solve it? Or more to the point how is sharing suppose to realistically work if you don't. If you say you're going to allow people to share files then you have to account for the very common scenario of simultaneous use.

And (as I said below and got downvoted for) it isn't that hard. We use Dropbox for Teams and I back it up with a custom application using components from a company named Aspose. They allow me to read Office file formats and combine files where needed.

If I can do that in a weekend then why shouldn't Dropbox look into doing it?

Can you explain how you merge two PDF documents that started as a single document, and was edited by two people at the same time? What do you do when they edited the same part of the document? And what about Word, JPEG, MOV etc.?

In source control systems like Subversion the application can usually automatically merge changes that happen in different parts of the document, but will require user intervention to merge conflicts. Merge conflicts can be difficult to resolve even in plain text. I really don't know how you could automate that in plain text files, let alone arbitrary file formats.

I almost think you're kidding here. It's called a popup.

You use Dropbox's already existing functionality to make a copy file. You then compare the changes and if they don't conflict you merge the files (while backing up both just in case of error). If they do conflict you send a message to the tray application which displays a popup showing the conflicts and asking for a choice. This isn't rocket science.

There are certainly places where that wouldn't be feasible like video editing. But I don't buy the argument that "because you can't do everything you should do nothing". Again I point out this took me a weekend to do with office documents and I didn't work through the night to accomplish it. So you can't really tell me it's out of the grasp of a company that has millions in funding.

Ok, so you haven't automated merge conflict resolution.

There are also cryptographically signed documents which you cannot merge, because that would break signatures.

So the question is, how much automated merge processing should be done, and how big are the risks in doing so. Even if the system were capable of doing merges for some documents, it would need to have a setting to turn it off. Recovering erroneously merged documents also needs some thinking. And so forth.

So bottom line is I guess we agree that in some cases merges can be done, automated to some level even, but there is a lot of work needed to make it safe, understandable and usable for the majority of users.

Reply on news.ycombinator.com