Difference between revisions of "Education ClassRoom/Previous Logs/MercurialMigration"

Revision as of 16:33, 11 November 2009

Soon on your screens :-)

[16:59] <ericb2> blauwal_: hello. thanks for accepting the presentation

[16:59] <ericb2> blauwal_: you can start :)

[16:59] <blauwal_> OK then let's go.

[17:00] <b_michaelsen> ericb2: huh? wiki root? anyway - later. blauwal_'s show ;)

[17:00] <blauwal_> My name is Jens-Heiner Rechtien and I'm with the OpenOfiice.org release engineering team

[17:01] <blauwal_> Lately we switched our Source Code Management (SCM) system from SVN to Mercurial and I'm going to tell a little about that

[17:02] <blauwal_> First I should say a bit about the WHY we did this

[17:03] <blauwal_> About a year ago we switched to SVN as an intermediate step and promised to re-evaluate the SCM situation again within a year.

[17:05] <blauwal_> This is because many developer wanted a distributed SCM (DSCM) system, but we found the than existing ones lacking.

[17:05] <blauwal_> All the three "big" DSCM evolved a lot over the last year.

[17:06] <blauwal_> Git, Bazaar and Mercurial (hg)

[17:07] <blauwal_> And early this year we found that Mercurial and Git are able to host the OOo source code and Bazaar nearly so.

[17:07] <blauwal_> Why not just stay with SVN?

[17:09] <blauwal_> Well, SVN is not a distributed SCM, which is what many developers prefer nowadays. But then SVN also disappointed in several areas.

[17:09] <blauwal_> The new merge tracking inplemented in SVN-1.5 proved to be very buggy (at least in the beginning) and quite slow.

[17:11] <blauwal_> Also the implementation of file renames is quite limited, it's possible to view the history of renamed files, but it's not possible to forward changes made to file under the old name to the new name.

[17:12] <blauwal_> In the end SVN stopped our suffering from CVS but was not the tool we wanted to stay with for a long time.

[17:13] <blauwal_> So let's say a few words about DSCM before we go into the details of Mercurial.

[17:14] <blauwal_> All DSCM keep the complete history in a storage on the local disk.

[17:14] <blauwal_> That's why they are called "distributed", all copies of the repositories have the complete history.

[17:15] <blauwal_> There are a number of consequences which follow immediately.

[17:15] <blauwal_> a) Revisionnumbers can't be numerical anymore.

[17:16] <blauwal_> Consider two repositories with 100 changes in there. Developer A add change in his copy, developer B another change in her copy.

[17:17] <IZBot> News from cws: ooo32gsl03: nominated

[17:17] <blauwal_> Both would have a local revision number 101 but the changes are not identical.

[17:18] <blauwal_> So all DSCM use some kind of hash to identify changes, or more specifically changesets. For mercurial it's SHA1 hashes which are used.

[17:20] <blauwal_> Mercurial allows still local numerical revisions numbers, but they are valid for the local repository only. For exchange purposes always use the hashes.

[17:21] <blauwal_> b) All the history must be copied over and over

[17:21] <blauwal_> This is no problem with small repositories, but the OOo one is not small at all

[17:22] <blauwal_> So any setup which uses a DSCM for OOo source code hosting has to be very careful about not requiring developers to copy the same old changesets over the net again and again.

[17:22] <blauwal_> I'll come to that later.

[17:23] <blauwal_> c) Almost all operations on the repository are done locally. This is just great for speed. You'll notice it when you do merge work for instance.

[17:24] <blauwal_> Actually all DSCMs are great with regard to merges, this is because this operation is at the heart of the workflow with DSCMs.

[17:25] <blauwal_> d) You can do most of your work without Net access - which is great if you are on a flaky line

[17:26] <blauwal_> e) There is no central repository.

[17:27] <blauwal_> This means any DSCM setup requires a number of conventions. The nice thing about this that you can tailor the conventions to your needs

[17:28] <blauwal_> So how does working with Mercurial looks like? Let's explore this with an example. You can find the whole documentation in the OOo wiki.

[17:29] <ericb2> blauwal_: got this page : http://wiki.services.openoffice.org/wiki/OOo_and_Mercurial

[17:29] <blauwal_> First you'll have to create a clone of the repository which is provided by OOo release engineering. Let's call this the master repository, its name is DEV300

[17:29] <blauwal_> ericb2: yes, that's the entry point

[17:30] <blauwal_> If you have time and band-width just do:

[17:30] <blauwal_> hg clone -U http://hg.services.openoffice.org/DEV300 my_local_DEV300

[17:31] <blauwal_> There are faster ways to do this, please have a look at the documentation.

[17:32] <blauwal_> Now you have got a treeless copy of the DEV300 repository on your disk. Update it regularly with:

[17:32] <blauwal_> cd my_local_DEV300

[17:32] <blauwal_> hg pull

[17:32] <blauwal_> You could implement a cron-job for that.

[17:33] <blauwal_> Now, you'll need a working copy to actually do something with it.

[17:33] <blauwal_> hg clone -r DEV300_m66 my_local_DEV300 my_working_copy

[17:34] <blauwal_> This will create a working repository - with source tree - which contains everything up to DEV300_m66 or whatever milestone you specify.

[17:35] <blauwal_> cd my_working_copy

[17:35] <blauwal_> ... hack away ...