monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: silly question #2: why base64?


From: Christof Petig
Subject: Re: [Monotone-devel] Re: silly question #2: why base64?
Date: Fri, 23 Sep 2005 09:27:38 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050912)

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]