monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: [HACKERS] SCMS question


From: hendrik
Subject: Re: [Monotone-devel] Re: [HACKERS] SCMS question
Date: Fri, 23 Feb 2007 10:01:46 -0500
User-agent: Mutt/1.5.9i

On Fri, Feb 23, 2007 at 11:28:07AM -0300, Alvaro Herrera wrote:
> address@hidden wrote:
> > On Fri, Feb 23, 2007 at 10:42:13AM -0300, Alvaro Herrera wrote:
> > > Richard Levitte - VMS Whacker wrote:
> > > > In message <address@hidden> on Fri, 23 Feb 2007 07:57:53 +0100, Markus 
> > > > Schiltknecht <address@hidden> 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




reply via email to

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