User: Password:
Subscribe / Log in / New account



Posted May 14, 2011 12:50 UTC (Sat) by loevborg (guest, #51779)
In reply to: DVCS-autosync by drag
Parent article: DVCS-autosync

I agree completely. DVCS are useful for plain text, which for almost anyone except programmers is only a tiny portion of your data. Using git doesn't gain you anything, because we can't use diff for ODF etc. What we need is pretty much a drop-in replacement for dropbox.

With all due respect, this seems the expression of a sort of narrow-mindedness typical of programmers. People who work with source code all day assume that code is the model of computer work. However, code is actually very particular. What we really need is a place to store our letters, PDF forms, spreadsheets and so on, which are quite different from code in many respects.

The situation is similar in the field of text editors. Here every week or so someone starts a new editor which targets ... programmers. But there still is hardly a single text editor which is any good for writing simple English language prose! Here there is little use for syntax coloring, line numbers, nonproportional fonts. Instead you need configurable line spacing, easy-to-read proportional fonts, paragraph-based (not line-based) navigation, word-wrapping, etc. Still instead of solving this very real problem, people come up with new solutions to already solved problems.

(Log in to post comments)


Posted May 14, 2011 13:08 UTC (Sat) by nix (subscriber, #2304) [Link]

Actually, you can plug in domain-specific diff/merge tools into git (OpenOffice documents were a named use case for this). Obviously the merge tools for binary stuff need their own way to do conflict resolution as well.

Git is exactly as efficient at handling binary files as handling text files: you have to go back to CVS to find something that isn't good at binary files.


Posted May 19, 2011 5:07 UTC (Thu) by smurf (subscriber, #17840) [Link]

There are a couple of document formats which are singularly not suited for VCSes, though.

OOo documents, for instance, are compressed XML files. There's no sane way to store multiple versions of these in a git archive. Store them uncompressed (dunno how to teach OOo that) and you get a signficant decrease in storage requirements, long-term.

Still needs a domain specific conflict rresolver, of course. You could probably script your way into LibreOffice to do it, though it's nontrivial.


Posted May 19, 2011 5:20 UTC (Thu) by dlang (subscriber, #313) [Link]

actually, since git does the compression itself, the answer is to have git uncompress the documents and version the uncompressed data. then when you check it out git assembles the version you want, then compresses it as you check it out.

you can even insert XML aware diff engines if you want.


Posted May 26, 2011 19:43 UTC (Thu) by nix (subscriber, #2304) [Link]

Yes indeed. 'man gitattributes' and search for 'filter' for something that may help here.


Posted May 14, 2011 19:40 UTC (Sat) by elanthis (guest, #6227) [Link]

You mean... people who _write code_ think like people who _write code_?

How surprising.


Posted May 14, 2011 20:45 UTC (Sat) by dlang (subscriber, #313) [Link]

it's not that git is especially inefficient at handling binary files, it's that the compression and other efficiencies that git can get with text files don't work on binary files.

but git is not any worse in dealing with binary files than any other solution where you want to be able to retrieve any version that ever existed.

that said, git does have some limitations in terms of max sizes of things


Posted May 14, 2011 21:45 UTC (Sat) by drag (subscriber, #31333) [Link]

So when I want to share my 800MB movie with a friend or have it available on another machine it's just not going to happen.

From dropbox's website:
> Files uploaded to Dropbox via the desktop application have no file size limit.

> Files uploaded through the website (by pressing the upload button) have a 300 MB cap. In other words, each file you upload through the website must be 300 MB or less.

> All files uploaded to your Dropbox must be smaller than the size of your Dropbox account's storage quota. For example, if you have a free 2 GB account, you can upload one 2 GB file or many files that all add up to 2 GB. If you are over your storage quota, Dropbox will stop syncing until you are below your limit.

Dropbox's revision control system is optional and only will save revisions for 30 days. Many people want sync software to sync a significant amount of data.... I am guessing that for most people's purposes revision control is much less important then just automatic syncing.

The ability to carelessly drop a file into your drop box and have it automatically available on any machine you happen to want to use is the 'killer feature' for Dropbox. The idea of trying to do something like manage a 4GB mp3 collection using something like Git commit sounds like a nightmare to me.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds