[FoRK] [linux-elitists] Ledger: org mode for double-entry bookkeeping

Eugen Leitl eugen at leitl.org
Sat Dec 8 01:44:13 PST 2012


----- Forwarded message from Nathaniel Smith <njs at pobox.com> -----

From: Nathaniel Smith <njs at pobox.com>
Date: Fri, 7 Dec 2012 20:45:42 +0000
To: linux-elitists at zgp.org
Subject: Re: [linux-elitists] Ledger: org mode for double-entry bookkeeping

On Fri, Dec 7, 2012 at 3:17 PM, Don Marti <dmarti at zgp.org> wrote:
> (By the way, I'm now at Perforce, working on related
> problems among other things.  Although I prefer to use
> applications of the future, a lot of people are still
> using current mass-market desktop applications that
> failed to understand git-merge-friendly principles
> when designing their on-disk formats, which is
> understandable considering how much longer than git
> they've been around.)

Last I checked, git's merge algorithm has a lot more heuristics than
principled guarantees, which makes the idea of "git-merge-friendly
principles" more vacuous than would be ideal. It's sort of a shame,
since we actually solved the problem of merging complex structured
data in monotone. We used it for merging arbitrary mixes of
file/directory renames, but the principles are more general:
  http://thread.gmane.org/gmane.comp.version-control.monotone.devel/4297
  http://thread.gmane.org/gmane.comp.version-control.revctrl/93
  http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9781
Unfortunately we only did this *after* git and mercurial's designs
"forked off", so the ideas haven't really had any influence. Plain
text is actually about the worst case for merging; AFAICT there are
still *no* algorithms that don't blow up and do horrible things in
some situation or another, because the linear ordering of lines turns
out to be a particularly nasty data structure to work with. Merging
trees, graphs, email message flags, contact fields, etc. etc. are all
totally doable though.

If I wanted to be an engineer when I grew up, then I'd convince
someone to pay me to write a sort of bastard child of sqlite and git,
where you could write a description of complex data structures and it
would implement
chained-hash-synchronization/delta-compressed-storage/provably-good-merge-algorithms,
with a clean API to expose conflicts to the app as structured
first-class entities and other niceties useful for synchronizing apps
(e.g., pruning history, in case you don't need 15 years of edits to
your mail store or calendar). Couchdb kind of wants to be this, but
last I checked couchdb doesn't even record merges in its internal
history graph, so it's doomed.

Unfortunately I decided to be an academic instead, so, no time.

-n
_______________________________________________
Do not Cc: anyone else on mail sent to this list.  The list server is set for maximum one recipient.
linux-elitists mailing list
linux-elitists at zgp.org
http://zgp.org/cgi-bin/mailman/listinfo/linux-elitists

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


More information about the FoRK mailing list