RSS Feed
Bookmark to Delicious
Thursday, 23 Apr 2009
accessibility
api
architecture
automated_tests
base
beta
build
calc
chart
code
community
database
development
directx
document
download
draw
eis
events
export
extensions
features
filter
framework
graphics
gsl
gsoc
gullfoss
import
impress
installation
iso26300
java
l10n
localization
mac
netbeans
odf
ooo
ooocon
ooocon2008
ooocon2009
open
opendocument
openoffice
openoffice.org
pdf
performance
porting
qa
quality
quaste
release
renaissance
security
snapshot
software
specification
spreadsheet
staroffice
statistics
sun
survey
testing
toolkit
tools
usability
user-experience
video
web
wiki
writer
xml
- show all articles
Thursday, 23 Apr 2009
Jens-Heiner Rechtien
Last September, the OOo community adopted Subversion as our SCM (Source Configuration Management) tool. Those who followed the discussion closely might remember that Subversion was not considered the last word on SCM tools for OOo but as an intermediate step towards a distributed SCM system.
Subversion was chosen as an intermediate step because during the initial evaluation we felt that the three major DSCM systems (Bazaar, Mercurial and Git) were not ready for a large code base like the OOo one, with the possible exception of Git, maybe.
Since then a lot has happened. A re-evaluation of the DSCM systems showed that at least Git and Mercurial are now ready for hosting the OOo code base. The same might be true for Bazaar once it adopts its new development6-rich-root repository format as default format, which came a bit to late for our evaluation.
Choosing between Git and Mercurial is like choosing between Vi and Emacs. Doesn't matter which one you choose, you'll hear some passionate arguments about it. After all is said and done, it comes down to a choice between a slightly more flexible system (Git) vs. a slightly more accessible system (Mercurial). And yes, even this assessment will be hotly contested, I know. Anyway, other very knowledgeable bloggers come to a similar conclusion.
Without a clear technical reason to rule out either git or mercurial the ESC meeting decided to conduct a survey of opinions inside the OOo community, which was organized by Stefan Taxhet. The bottom line: "The system of choice is for 3% Bazaar, for 23% Git and for 49% Mercurial. 25% had no preference."
Release Engineering slightly prefers Mercurial as well so it was decided to start a Mercurial pilot, as announced by Martin Hollmichel.
The exact details of the Mercurial (hg) pilot will be posted separately. But so far I think it will go along the following lines:
- The main hg repository is hosted on svn.services.openoffice.org (maybe it should be hg.services.openoffice.org?) and is continually updated from the Subversion repository.
- The pilot will be open for the main development code line (DEV300).
- We plan to have a separate repository for each major code line. The alternative would be to have stable code lines as "named branches" in the main repository but this seems to be not optimal. Anyway, this point is not finally decided.
- There will be outgoing repositories on the server as well, to publish your work/CWS. Write access is possible via ssh - we'll reuse the subversion public keys for that, no need to submit new ones.
- The pilot will run at least two month. This is to check if updating ("sychronizing") old CWSs does work well.
- If your work/CWS is finished you'll need to pull/merge one last time. This is necessary to ensure that release engineering can apply clean patches to the - still svn hosted - main codeline during CWS integration.
Mathias Bauer and his team has volunteered to participate in the Mercurial pilot. Thanks for that! You can participate as well, just send me (hr) an email.
tags:
Digg this
Comments
Hi Heiner,
great to see this happening! Some random nitpicks:
- If we really change the domain, instead of using svn.services.OOo or hg.services.OOo maybe we should use scm.services.OOo so the URL wont be bound to a product
- What exactly is meant by "separate repository" for each codeline? Simply, that when we fork off OOO320 of a DEV300, the OOO320 repo will be not contain DEV300 changes from that point on and vice versa? Because I cannot see how that alone would be a problem as long as they have a shared history (and thus are easily mergeable, if the need arises). Or will the forked release branch be "from scratch" and thus not share a history with the mainline? If so, why?
- Having outgoing repos is fine, but I wonder if we really need ssh access to them. Just a crude thought: If we would have a "hg pull" button in EIS, we might be able to save ourselves the whole hassle with keys.
Anyways, great news, looking forward to having fun with the pilot!
Best Regards,
Bjoern
Posted by Bjoern Michaelsen on April 23, 2009 at 06:06 PM CEST #
@Bjoern:
1) prefixing the URL with 'svn' and 'hg' is a useful convention which people expect. Most do not know what is meant which 'scm'.
2) separate repositories will share the history only up to the point where the "release code line" is cloned from the "development code line". In practice RE will "transplant" or "cherrypick" changes from the "release code line" to the "development code line" but of course not the other way round. Thus the "development code line" will typically contain all change sets from both code lines. Comparisons between the two code line must be done with cross tree comparison tools.
3) You'll need to have outgoing reps on the server for publishing your stuff. Think collaboration, tinderboxes and buildboxes etc. Also I want *one* place where RE can pull stuff from the repositories of finished CWSs for integration. Where should this be if not the server everyone uses?
Posted by Jens-Heiner Rechtien on April 23, 2009 at 06:33 PM CEST #
to 1) you are right.
to 2) Ah, I understand. However, if both codelines have shared history I still would consider merging both codelines in a local repo (pulling from both) for comparisons instead of using other tools. Obviously one shouldnt push from that (local merged) repo to any codeline repo because that would add the other codeline into the repo too. Anyway, I guess, what one does locally is a matter of taste anyway.
to 3) I didnt want to get rid of the outgoing repos (cws). I was just thinking about the need to have keys for devs to control that repo. If I had a webinterface where I could tell my cws repo "please pull changes from $URL", we wouldnt need another authentication (ssh-keys) to control the cws. However, then the dev would need to take care himself to publish his working copy at $URL so it can be pulled. In the end, Im not sure if anything is gained by this ...
Posted by Bjoern Michaelsen on April 23, 2009 at 11:34 PM CEST #
As a member of the Mercurial crew, I like where this is going! Let me know if I can do anything for you guys. Is there a not-too-busy IRC channel where this is being discussed? I'm also on twitter, @djco.
Posted by Dirkjan Ochtman on April 24, 2009 at 10:13 AM CEST #
@Dirkjan: great, thanks for the offer! The OOo development channel is #dev.openoffice.org at freenode, my nick is blauwal. I'll subscribe to the Mercurial mailing lists as well. And actually yes, there is one thing I could use a little help with. During conversion of the OOo SVN repository I'm stumbling over issue 1396 (http://www.selenic.com/mercurial/bts/issue1396), if there is progress on this issue I would like to now.
Posted by 192.9.112.196 on April 24, 2009 at 01:31 PM CEST #