Difference between revisions of "Education ClassRoom/Previous Logs/OOo svn migration"

Revision as of 15:36, 8 October 2008

[17:00] <ericb2> blauwal: let's start ?

[17:00] <blauwal> ericb2: yes, let's start

[17:00] <ericb2> blauwal: thanks a lot for accepting to be there :)

[17:00] <blauwal> Thank you for the invitation Eric

[17:00] <ericb2> blauwal: you're welcome !

[17:00] * fardad is all ears (eyes)!

[17:01] <blauwal> I'm going to say a bit about the OOo subversion migration

[17:01] * ronyf (n=chatzill@abt-wi-018.wu-wien.ac.at) has joined #education.openoffice.org

[17:01] <blauwal> I've prepared a (very) few slights and linked them to the eduction page in the Wiki

[17:01] * chacha_chaudhry (n=dev@gnu-india/supporter/rakeshpandit) has joined #education.openoffice.org

[17:01] * ChanServ gives channel operator status to chacha_chaudhry

[17:02] Balise blauwal

[17:02] <blauwal> I'm a lousy typist, so please bear with me

[17:02] <ericb2> blauwal: :)

[17:02] <blauwal> CVS is aging as you all know and we got a lot of pressure to work with something better

[17:03] <ericb2> The link : http://tools.openoffice.org/scm_migration/subversion_migration.pdf

[17:03] <blauwal> We had a long discussion about what to use, a DSCM or Subversion

[17:03] <blauwal> We evaluated a number of DSCM and found them all lacking in one aspect or another, so we finally choosed SVN

[17:04] <blauwal> but we'll keep the eyes open and reevaluate the DSCMs from time to time

[17:04] <blauwal> 1) slide

[17:05] <blauwal> The CVS server on CN is not exactly known as the fastest one so we made sure that our new server is fast.

[17:05] <blauwal> It should never be a bottleneck.

[17:06] <blauwal> We hope that the 4 CPU 8 cores 64 GB should suffice for a time

[17:06] <blauwal> The network connectivity is also quite good, but can't be really controlled by us, of course. The server is located in Las vegas

[17:07] <blauwal> Over time we'll probably add a few services on that machine, the first one will be OpenGrok, a fast indexer and LXR replacement

[17:08] <blauwal> We've got a backup server in case something goes seriously wrong. We hope that we can achieve a pretty good reliance with this setup.

[17:08] <blauwal> next slide ...

[17:09] <blauwal> One of the critical features we need from a SCM system is merge tracking. Here do the DSCMs (mercurial, git, bazaar) really shine, becuase mergetracking is kind of immanent in them

[17:10] * rtimm (n=Ruediger@sd-socks-197.staroffice.de) has joined #education.openoffice.org

[17:10] <blauwal> Subversion introduced merge tracking with Subversion 1.5, so we really need to use 1.5 SVN clients

[17:10] <blauwal> Best is to always use the latest one (1.5.2 at the moment)

[17:11] * humph (n=dave@cdot.senecac.on.ca) has joined #education.openoffice.org

[17:11] <blauwal> Branching and tagging is implemented in Subversion as "paths" into the repository. Thus the repository layout deserves a few word.

[17:13] <blauwal> All "paths" in SVN are accessed via an URL. For instance the trunk or head revision can be accessed via sv://svn.services.openoffice.org/ooo/trunk

[17:13] <blauwal> s/sv/svn

[17:13] <blauwal> when we create a milestone, the we do a svn copy operation from trunk to tags, ie

[17:14] <blauwal> svn copy <...>/ooo/trunk <...>/tags/DEV300_m32

[17:14] <blauwal> this copy is a "copy-on-write" operation, it takes only a tiny bit of space in the repository

[17:15] <blauwal> branches are created with the same command, ie

[17:15] <blauwal> svn copy <...>/ooo/trunk <...>/branches/OOO310

[17:16] <blauwal> so, if you are looking for a milestone, check the .../tags path

[17:16] <blauwal> for a (major) branch it's .../branches

[17:16] <blauwal> and for a CWS, you guessed it, .../cws

[17:17] <blauwal> there are a few other paths in there like ../contrib .../vendor .../patches which are for stuff which aren't really meant to go in the main development line

[17:18] <blauwal> We do not employ a path based access restrictions. If you got write access to the repository you can change things everywhere, but we think it's good enough to use just some conventions

[17:19] <blauwal> we'll see if this works.

[17:19] <blauwal> next slide ...

[17:20] <blauwal> You can access the repository via svn://, http:// and svn+ssh:// methods, the first two are read-only, the last one is the read/write access method. You'll need to provide a public

[17:20] <blauwal> key for write access

[17:21] <blauwal> svn+ssh:// is basically a svn protocol over a ssh tunnel

[17:21] <blauwal> next slide

[17:21] <blauwal> We had to modify the CWS tooling of course ...

[17:21] <blauwal> because it was ingrained with CVS special things

[17:22] * riddle28 (i=ca9929ab@gateway/web/ajax/mibbit.com/x-fa6fef1e35ff3f4d) has joined #education.openoffice.org

[17:22] <blauwal> Now there is just one script which replaces the number of cwsxxx tools we had

[17:23] <blauwal> "cws create" is for the creation of CWSs, it creates the CWS branch in the repository and registers a CWS with EIS

[17:24] <blauwal> With "cws fetch" you can check out your CWS, alternatively you can also just use "svn checkout <.../ooo/cws/mycws" of course

[17:24] <blauwal> "cws rebase" is the replacement for cwsresync and makes use of the subversion mergetracking feature.

[17:24] <blauwal> next slide

[17:25] <blauwal> the other cws commands are there as well

[17:25] <blauwal> next slide

[17:25] * rtimm (n=Ruediger@sd-socks-197.staroffice.de) has left #education.openoffice.org

[17:25] <blauwal> finally I want to say a few things about what exactly has been migrated.

[17:26] <blauwal> Naively one would think that a migration involves the conversion of the whole project history

[17:27] <blauwal> This is not really possible, because it would take almost forever for a project of the size of OOo.

[17:27] <blauwal> I broke of my trials after about a month or so of conversion time :)

[17:28] <blauwal> Next one could think of a full migration minus all the "finished" CWS branches (5000 or so). This is feasible but still takes a week or so and results in a 90 MBytes repository

[17:29] <blauwal> sorry 90 GB repository

[17:30] <blauwal> Way easier is to migrate only the trunk history, that means no historic branch, or tag will be in the SVN history. Also, only active files are migrated and only the last revision of binary files

[17:30] <blauwal> And the most radical approach is of course to migrate no history at all.

[17:31] <blauwal> To make the long story short, we choosed the "trunk only" approach. The main reason for this is, that we didn't have any down time for the developers.

[17:32] <blauwal> the next slides contain a discussion about the pros and cons of the migration methods, but I think we should break here for a Q&A session

[17:32] <ericb2> blauwal: ok

[17:33] <blauwal> OK keep the questions coming :)

[17:33] <chacha_chaudhry> blauwal: so CVS server will remain up ?

[17:33] <blauwal> yes.

[17:34] <blauwal> All old branches will be maintained via CVS

[17:34] <ericb2> blauwal: so the history is safe ?

[17:34] <chacha_chaudhry> blauwal: Just curious, how many active CWS are now ?

[17:34] <blauwal> Yes. There will always be a at least read only server

[17:35] <blauwal> I think there were some 700 or so

[17:35] <ericb2> uff

[17:35] <blauwal> The question is, how many of them are really active

[17:35] <ericb2> blauwal: or waiting for QA resp :)

[17:35] <blauwal> :)

[17:35] * ericb2 has several cws in this case

[17:36] <chacha_chaudhry> It would have been real pain with 90 GB repo. :)

[17:36] <blauwal> you have to see the number in comparison to the number of closed CWS: >5000

[17:36] <blauwal> yes, hard to sync

[17:36] <blauwal> the trunk only solution resulted in a repository of about 6 GB