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
