Education ClassRoom/Previous Logs/MercurialMigration
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 ...
[17:35] <blauwal_> hg commit -m"#4711# my changes to fix issues 4711"
[17:36] <blauwal_> The nice thing is that you don't need to be a domain developer, or even be known to the OOo community to do this.
[17:36] <blauwal_> Everything just happens on the local disl
[17:36] * Matt1 has quit (Nick collision from services.)
[17:36] <blauwal_> s/disl/disk/
[17:37] * matoosss is now known as Matt1
[17:38] <blauwal_> Say, you have worked a while, committed a number of changes and now want to merge new changes from the master repository into your working tree
[17:39] <blauwal_> You can do this by pulling the new changes from your (updated) copy "my_local_DEV300", or by pulling the changesets directly from http://hg.services.openoffice.org/DEV300
[17:39] <blauwal_> Let's assume we do the latter:
[17:39] <blauwal_> cd my_working_copy
[17:40] <blauwal_> hg pull http://hg.services.openoffice.org/DEV300
[17:40] <blauwal_> ... fetches new changes
[17:40] <blauwal_> hg merge
[17:40] <blauwal_> If you got conflicts, resolve them:
[17:40] <blauwal_> and mark them as resolved
[17:41] <blauwal_> hg resolve -m <resolved_file>
[17:41] <blauwal_> and finally commit the result of the merge
[17:41] <blauwal_> hg commit -m"merge with DEV300 m70"
[17:42] <blauwal_> Your working copy is now up-to-date with the latest changes.
[17:42] <blauwal_> Mercurial allows you to configure your merge-tool of choice.
[17:44] <blauwal_> One merge-tool which has a very good reputation is "kdiff3". Or you can just fall back to the style of auto-merging with conflict markers which are known to all CVS and SVN users. Your choice.
[17:45] <blauwal_> So, you got a fix for OOo and want to contribute it, how to do this?
[17:46] <blauwal_> You could export your change as patch via hg export and send it to the mailing lists for review.
[17:47] <blauwal_> If the patch is accepted it will be integrated with all the Meta-data (author name, date, commit message) intact.
[17:48] <blauwal_> If you got larger changes to contribute have a look at the "patchbomb" extension of Mercurial.
[17:49] <blauwal_> Domain developers can contribute directly to OOo without the detour via the mailing lists.
[17:51] <blauwal_> When a domain developer create a so called child workspace (CWS - that's the major vehicle for OOo development), a clone of the master repository with all the changes up to the "creation milestone" of the CWS is created on the OOo repository server
[17:52] <blauwal_> We call these repositories "outgoing repositories". It's the central collaboration point for developers.
[17:53] <blauwal_> Domain developer can "push" their changes to that server, RE will take the changes from there for integration.
