[kwlug-disc] rcs (git?) integration/prevalence? [Was: CSS: varying colours based on inheritance]
cdfrey at foursquare.net
Fri Jul 8 02:17:23 EDT 2011
On Fri, Jul 08, 2011 at 01:31:54AM -0400, Kyle Spaans wrote:
> The problem here isn't a GUI or lack thereof. The problem is content.
> Git (and most RCSes) are built around versioning and diffing plaintext
> files (some are better/worse at version binary files). The unit of
> currency in Git-land is the patch, generated by `diff`. OO.org files
> are not plaintext, so trying to integrate git into OO.org runs you
> into the problem of "Well, git isn't totally meant for binary files".
> On the other hand, (not knowing anything about the versioning system
> in OO.org) with binary diffs or a special diff that understands the
> structure of OO.org documents, you can build a versioning system -- it
> won't necessarily have the same interface as Git though: you commit
> changes, see a version history, and roll-back when needed.
> But now if your "word processor" was some plaintext editor, IDE or
> OO.org in plaintext mode, then it's trivial to present a GUI interface
> with buttons for each of the git commands.
Sorry, but I gotta correct this. :-)
While some SCM's are diff-based (such as CVS, and I think arch),
git is not. Git stores each revision of a file as a separate copy
in a compressed file under the .git directory, using the SHA1 sum
as the filename / directory name.
Git only cares about diffs when it combines all these separate revision
files into an optimized .pack file. Then it does store diffs. But
that is just an optimization.
As for OpenOffice documents, the crazy thing about them is that they *are*
just text files. If you run 'unzip -l' on an .odt file, you'll see a
bunch of XML files.
All that said, the argument is somewhat valid for files like JPG or
even GPG documents, which may not diff very well.
But I think this is beside the point of a filesystem that stores file
revision history automatically. A filesystem does not need to worry
about compression, and could store the revisions the same way that
git does: a separate file for each revision. This would take care
of the binary file issue.
It would be nice if the filesystem also purged old revisions automatically
when it started running out of space.
The more I ponder this, the more I think this could be done by writing
a FUSE filesystem driver with a git backend....
And what do you know? gitfs and figfs already exist. I wonder if
they do what we want. If not, maybe combining with something like
git-annex or bup would work.
This project needs programmers with free time. :-)
More information about the kwlug-disc