[Top][All Lists]
[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