Lapo Luchini schrieb: >>>Problem 1 is that binary data is ugly to handle on screen or debugging >>>output. > > > On the other hand a diff on a "normal" text file is way more elegant > seen in text than in base64 (even if I guess that xdelta diffs have got > a bit of binary data in them anyway, at least some pieces would be > understandable text, wouldn't they?).
Not to mention the ability to query for meaningful cert values:
select count(*) from revision_certs where name='cvs-revisions' and value
like 'Y3ZzLm1hbnVwcm9jLmJlcmxpb3MuZGU6L2N2c3Jvb3QvbWFudXByb2Mv%';
is _much_ worse than:
select count(*) from revision_certs where name='cvs-revisions' and value
like 'cvs.manuproc.berlios.de:/cvsroot/manuproc/christof%';
>>>Problem 2 is a transparent migration scheme for the user (that's
>>>not trivial).
>
>
> As a first stop-gap we could modify base64encode not to encode and
> base64decode to accept both encoded and non-encoded, on the assumption
> that non encoded data will have at least SOME non base64 data? but this
> assumption is a bit ugly and would complicate things to manage data in
> BOTH formats at once... unless we decide to put a non-base-64 char as a
> first char, to help specifically the decoder decide if the record is new
> or old. This way even a single DB could be re-encoded step-by-step.
>
> But probably is much better to switch at once and offer the user to
> migrate it using a local "serve" + "sync" in a new DB and that's all..
db migrate would be even more preferable ;-)
(I talked about this to NJS, you should be able to find his answer in
the archives, searching for me and BLOB should show the way)
Christof
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
