From kde-core-devel Fri Oct 08 20:45:56 2004 From: Sandro Giessl Date: Fri, 08 Oct 2004 20:45:56 +0000 To: kde-core-devel Subject: Re: Moving to SubVersion Message-Id: <200410082245.56085.sandro () giessl ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109726836717095 Am Friday, 8. October 2004 21:31 schrieb Jesse Yurkovich: > Quoting Tobias Koenig : > > 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.