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
branch/CWS
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
re-integration.
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.
Heiner
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1103360
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-04 19:51:11 CET