[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Moving to SubVersion
From:       Sandro Giessl <sandro () giessl ! com>
Date:       2004-10-08 20:45:56
Message-ID: 200410082245.56085.sandro () giessl ! com
[Download RAW message or body]

Am Friday, 8. October 2004 21:31 schrieb Jesse Yurkovich:
> Quoting Tobias Koenig <tokoe@kde.org>:
> > On Fri, Oct 08, 2004 at 09:04:14PM +0200, Stephan Kulow wrote:
> > > Am Freitag 08 Oktober 2004 20:31 schrieb Tobias Koenig:
> >
> > Hi Coolo,
> >
> > > > IMHO doing the change before 3.4 would be the best solution, so
> > > > we can concentrate on the new Qt version for 4.0 and have the
> > > > possebility to rename and move files which is really important
> > > > for the library cleanup.
> > >
> > > I agree to this argumentation. But we need a migration path and
> > > someone needs to work it out.
> >
> > Is there anything we developer can do? I guess most of the work
> > must be done by the people who have access to the server with the
> > repository.
> >
> > I'm fine with cvs.kde.org being not reachable for 2 or 3 days if
> > the migration would take so long.
>
> I think that with whatever repository we decide to go with, be it svn
> or whatever, we need to bring it up 'along side' cvs for a short
> while.  Let the devs transition over to the new one in the course of
> maybe 2 weeks; keeping the two relatively in sync. At the end of 2
> weeks, close access to cvs for all new commits and require committing
> in the new repository.
>
> Obvisouly the 2 weeks part is just an idea but something along those
> lines might make the most sense ... though keeping them in sync might
> be really expensive.
As far as I know it's currently nearly impossible to keep CVS in sync 
with something like Subversion. At least I don't know of any 
tool/script which would do this.
But IMHO an early announcement before the real switch takes place would 
be enough anyway.
[prev in list] [next in list] [prev in thread] [next in thread]