OpenOffice.org has migrated from CVS to subversion some time ago.The
OpenOffice development model does all the implementation of new features
and bug fixes on separate branches which get integrated (merged back)
after QA review. This had been done already on CVS by some scripting
around CVS, include some merge tracking (named resyncing on OOo, see
http://tools.openoffice.org/dev_docs/OOo_cws.html for some more
details). The major drawback on CVS were the time for the needed tagging
operations so the project was eager to migrate to some more modern SCM,
The merge tracking introduced with subversion 1.5 was thus a long
awaited feature to make OOo special scripting obsolete and let the SCM
natively do the job.
Now, having done daily work with subversion for some time now (see list
of cws in subversion http://svn.services.openoffice.org/ooo/cws/ ) and
done some more so resync or rebase action we run into the situation to
discover that svn diff or merge operation become time consuming for
those child workspaces (aka branches). Example: $ "svn diff
svn://svn.services.openoffice.org/ooo/tags/DEV300_m38" leads to some
hours waiting time. The then following merge to trunk is not faster. The
conclusion right now: some aspects have become more modern and
convenient than before but the big drawback OpenOffice has before with
CVS has not been solved: The overall process of branching, resyncing and
merge had become slower than before.
OpenOffice will now have some closer look to alternatives, especially to
some distributed SCM like git, mercurial or bazaar and to evaluate them
more in depth as this has been done for subversion before. Having an SCM
where a diff last longer than the compile of the complete stuff seems to
be a dead end for me.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-03 21:37:23 CET