On Fri, Feb 23, 2007 at 11:28:07AM -0300, Alvaro Herrera wrote:
[EMAIL PROTECTED] wrote:
On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote:
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Fri, 23 Feb 2007 07:57:53 +0100,
Markus Schiltknecht [EMAIL PROTECTED] said:
markus Uh, yah. But I was refering to the lots of opinions on what
markus replacement system to use. This has not much to do with the
markus want or need (for lack of a better alternative) to stay with
markus CVS, IMO.
Oh, it's an academic discussion? Sorry, didn't catch that.
It's only academic because Monotone is not ready. As soon as it is
ready we will be pushing much harder.
This invites the obvious question -- in which ways in monotone not
ready? Not that I'm trying to imply that monotone *is* ready, of
course.
Time to get the initial pull is too long, mostly. Also, having the
policy branch stuff will be good, if nothing else because it'll mean
having 1.0 out, in turn meaning UI stability, etc. And getting Markus'
work on the CVS import will be good too (I haven't tried converting
Postgres' entire CVS repo in a while, and that certainly is a must).
I don't think we're going to get a one-shot migration, so Cristof's work
on CVS takeover would be really nice to have so that some of us can
create an alternative repo and cater for those that will continue to
use CVS for a while.
Yes, interoperability with other revision management systems is a
problem for all of the revision management systems. It might be
de-facto-solved it one system manages to talk effectively to the
important other ones -- it won't be solved permanantly until there are
adequate standard, system-independent protocols ... I don't see that
coming soon.
And there;s the problem of welcoming the prodigal son.
A file gets away from the revision management system, and. much later,
returns, much changed from the experience. How should we slot it back
into the system?
-- hendrik
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match