monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] PostgreSQL support


From: joel reed
Subject: Re: [Monotone-devel] PostgreSQL support
Date: Wed, 12 May 2004 10:28:57 -0400
User-agent: Mutt/1.5.5.1i

On Tue, May 11, 2004 at 09:17:04PM -0700, Nathaniel Smith wrote:

snip

> > 1) much more familiarity and comfort with PostgreSQL than SQLite, 
> > regarding tools, drivers, scalability, etc.
> > 
> > 2) the customized SQLite page size seemed to make mono's SQLite driver
> > barf, which made me concerned about interoperability with other SQLite
> > drivers, like SQLiteODBC.
> 
> This doesn't seem like that big concern to me.  It's great for
> emergencies that Monotone repositories can be gotten at with raw SQL,
> but aside from such exceptional situations, you really don't want to
> go poking around in there by hand.  The storage representation is
> somewhat idiosyncratic, has changed in the past, and is liable to
> change in the future.  You already have to be able to read Monotone's
> proprietary delta format, for instance, to get useful file/manifest
> data out of it.

ok, so perhaps what we need is a libmonotone. i personally 
cringe at the thought of writing a web "viewcvs" like tool for monotone
without such a library, if direct db access if out of the question.

> 
> So the point is, interoperability, availability of tools, etc. are
> mostly irrelevant; better to just improve Monotone's scriptability.

in my opinion, monotone is prematurely limiting interoperability
with a customized SQLite pagesize. who knows what a more interoperable
SQLite db might bring? i'd say its too early to know, so too early to limit.

> 
> > 3) i was intrigued by the possibilites of exposing a single
> > PostgreSQL repository to multiple monotone clients, rather than exposing
> > a monotone server.
> 
> Intriguing, I agree, but I'm not sure what the practical use would be?
> One of the flaws in CVS is that to give someone (remote) write access
> to the repository, you basically have to give them full write access
> to the actual files that compose the repository, meaning they can
> spoof things, change history, etc. -- big security hole.

i coming at this one from the perspective of a manager of a team
of programmers using CVS, everyone is a trusted employee. it feels like
an easier stepping stone from CVS to monotone distributed VC to be
able to expose a single PostgreSQL repository to multiple monotone clients.

jr




reply via email to

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