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

[Nathaniel Smith]

On Fri, Sep 23, 2005 at 09:27:38AM +0200, Christof Petig wrote:
> 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%';

But hardly worse at all compared to the real:

select count(*) from revision_certs where name='cvs-revisions' and
unbase64(value) like 'cvs.manuproc.berlios.de:/cvsroot/manuproc/christof%';

:-)

(You can't do this in normal code, it's very inefficient because it
can't use an index, but it's fine for command line messing-about.)

> >>>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 ;-)

Yes, 'db migrate' is obviously the way to go.

The actual migration is probably not that hard to write, just some
update statements.  Might have to do some minor kluge to get the db
schema version to change, but that is trivial...

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen