[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: OpenOffice.org has migrated to subversion

From: Jens-Heiner Rechtien <jens-heiner.rechtien_at_sun.com>
Date: Wed, 04 Feb 2009 19:49:20 +0100

Mark Phippard wrote:
> >> Have you run svn-populate-node-origins-index on the repository?
> >> I think it would greatly help with such speed issues.
> > hmm, since the repository has been created with 1.5 and has not migrated
> > from an older server version I wouldn't expect that this helps,
> Right. If you created and loaded your repository using 1.5 binaries
> you would not need this. It also does not impact diff which you said
> was taking a long time.
> Can you give examples of commands you are running and the time?
> Diffing two URL's can be slow on any repos. But if you are in a
> branch and you run something like:
> svn merge ^/trunk
> To synch up on all changes, I'd think this would not take hours, even
> on a large repository like yours.

Our workflow at Openoffice.org looks more or less like this:

1) Release Engineering publishes milestones on the main development line
more or less weekly. A typical milestone name would be, say, DEV300_38.

$ svn copy ^trunk ^tags/DEV300_m38

2) Developers then create so called "child workspaces" (CWS),
essentially glorified feature branches. Practically all development is
done on such "child workspaces".

If the tag copy for "DEV300_m38" was revision 265758, the CWS
"myfeature" branch creation copy looks like this:

$ svn copy ^trunk_at_265758 ^cws/myfeature
$ svn checkout ^cws/myfeature WC

3) More often than not developers have to sync up to a newer milestones
before they can finish their work, say in this case milestone
DEV300_m41, that is revision 267170.

$ cd WC
$ svn merge ^trunk_at_267170

This can be necessary for a number of times for a long running feature

4) RE integrates the feature branch/CWS into the main code line

$ svn co ^trunk
$ svn merge --reintegrate ^cws/myfeature

Actually, it's practically impossible to use --reintegrate due to
subtree mergeinfo, so we have to fall back to

$ svn merge -r^tags/DEV300_m41 -r^cws/myfeature

I think this kind of merges back to the main tree are called reflective
merges in the SVN community. A feature branch/CWS is dead after

We have noticed the following:

$ svn diff -r^tags/DEV300_m41 -r^cws/myfeature

tends to be very slow if there has been at least one sync up to a newer
milestone on the feature branch/CWS. The merge operations themselves
aren't that fast either.

We also had numerous problems with the svn:mergeinfo property due to
moving around files etc.

The underlying workflow was first implemented with a heavily customized
CVS setup (including crude scripted mergetracking etc) and we have very
much grown to like it. Are we doing something very stupid here?

> svn merge --reintegrate can be greatly sped up by running svn update
> first. If the WC is at a uniform revision it can use some algorithms
> that are significantly faster

We now recommend to do a "svn update" before every "sync up" merge
operation, and we certainly do it before reintegration. It might be that
in some cases the "sync up" operation was done into a mixed revision WC.
Can this have such effects *after* the successful merge and commit?

Thanks for any help here.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-04 19:51:11 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.