OOo developers, last week I asked the participants of the Mercurial pilot for feedback. Most have responded and I think we are now able to wrap up the pilot and come to a conclusion.
Over the last eight weeks 21 child workspaces have been created and worked on, three of them went the full way until being integrated back into the main code line. You can find an overview here: http://hg.services.openoffice.org/hg The responses covered a whole range of topics, which I try to break down in the following: Functionality: ============== - most importantly, no participant complained about missing functionality. - one participant mentioned that he's more comfortable with the git feature set, but added that he's also way more experienced with git. - at least one participant was positively surprised by some unexpected but very useful functionality, for example the powerful template engine. Disclaimer: that would be me ... Scalability: ============ - overall perceived good performance, some were even quite enthusiastic about it (SVN users are easy to please ...). - there were three mentions of sub-par performance which all have been investigated shortly: - unexpected slow clone times on a very old machine with slow disks and little memory: this machine was probably simply underpowered for use with Mercurial, which is somewhat memory intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. - unexpected slow update of the working tree: caused by using the pure python replacements instead of the hg native shared libs. This should be avoided by any project of the size of OOo. - very slow push to outgoing rep. via async DSL after pull/merging the DEV300_m51 milestone: caused by an over sized changeset in DEV300_m51, which moved 40% or so of our tree to another place. Very nice test for a worst case behavior. Emphasizes the need of server side copies for creating the outgoing repositories. - storage efficiency in the case of renamed large files is worse than what is possible with git. Ease of handling/Learning curve: ================================ - got a lot of positive feedback here and one neutral (like git better but don't know yet enough about hg to judge it fair) - a complete and working infrastructure (build bots, opengrok, required changes to build.pl, a hg plugin which deals with EIS and many other tools) need to be in place before we could start with production use. Conclusion: =========== The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some improvements here and there, but all-in-all the majority of the pilot participants is pleased with its functionality, scalability and especially the ease of handling. With an overall positive outcome of the pilot we move over to next phase: the implementation of a full scale migration to Mercurial. I'll keep you posted about the details. Thanks: ======= I would like to thank all the pilot participants for their work and their valuable discussions and insights. Regards, Heiner -- Jens-Heiner Rechtien h...@openoffice.org recht...@sun.com OpenOffice.org release engineer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
