Hi Zack,
reading the commit ML, I've taken notice that you propagated to
nvm.experiment.db-compaction as well. Just some quick notes from my side
to avoid duplicate work.
I've started to migrate to an internal binary representation of hashes,
the complete "id" now means "a binary id", and only hexenc<id> should
contain hex encoded ids. As a quick "make check" tells, this currently
doesn't quite work, because of intermixed binary and hex
representations. I'm trying to get rid of those - and already have a
bigger change pending (lots of added hexenc_{en,de}code calls).
I've been struggling somewhat with the vocab_macros.hh. What I wanted
was to disallow operator<< for a new type ATOMIC_BINARY, but still allow
(read: define) it for normal ATOMIC and ATOMIC_NOVERIFY types. However,
maybe due to the templates generated by ENCODINGs and DECORATEs, somehow
the compiler doesn't get that. Instead, an operator<< for a binary id
still compiles fine and only the linking fails, because there's no
operator<< for 'id's. And what's worse: the linker's error messages
don't help much, because they are not very detailed.
Anyway, all of that vocab cruft is very hard to grok, IMO.
Ideas?
Regards
Markus
P.S.: I'm really wondering about performance of that thing. You once
mentioned, that those hashes are stored in hex in revisions and
manifests - thus we'd often need to hex encode them anyway. While that's
certainly true, we might save some encoding steps when comparing against
a newly calculated hash.
Plus, there's the space savings, which might be negligible for single
revision_ids, but consider ancestry_maps, where we store lots of revids
in memory...
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel