Re: Very slow merge for Feature Branch

From: Stephen Armstrong <StephenArmstrong_at_nanometrics.ca>
Date: Fri, 01 Feb 2008 09:52:20 -0500

Bicking, David (HHoldings, IT) wrote:

-----Original Message-----
From: Stephen Armstrong [mailto:StephenArmstrong@nanometrics.ca]

-----------------< much history removed >-------------------

  

The command we were using is:

svn merge trunk@HEAD branch@HEAD trunk

Now, according to ancestry, branch has had most of it's files 
modified since it was created months ago. But since last time 
we ran this merge (and so synced all files) we've only 
modified 1 file. It still takes a while (apparently it's only 
7 min or so. Not 15-20 as I was led to believe), but as I've 
said, a new branch with the same amount of changes seems to 
happen almost instantly. I would assume this is because the 
diff uses ancestry to eliminate any that haven't been 
modified since branch creation and diff those that have.

It looks like getting our users to delete their branch and 
recreate it after merging all finished changes into trunk 
will solve the problem by keeping all branches young.
    

I suspect your merges are scanning back to the branch point, when that
is not necessary.  If I am correct, there are three better solutions.

1) when you merge, identify which revisions were merged in the commit
log.  The next time you merge, view that information, and only merge the
revisions that aren't already merged (usually the subsequent ones).

2) Use svnmerge.py, which adds properties to the projects that keep
track of already merged revisions, thus making the merge (potentially)
as easy as "svnmerge merge".

3) Use Subversion 1.5 and the merge tracking feature.

I'm interested in hearing if any of those improve your experience!

--
David
  

We are already using a home-grown approach that I suspect is much like #2. We've been waiting for svn 1.5 to come out, and when it does we'll probably upgrade once it's had a chance to 'settle' in the community for a couple months, and we've looked it over.

My company switched from Clearcase to SVN a month or two before I started, so the terminology we use comes from there I think.
Rebase - merge in all changes that have been done on trunk into your branch (keep your branch up-to-date with changes on trunk)
Deliver - merge changes you have done to your branch into trunk

Our rebase scripts use a property on the branch called 'lastrebase', so to keep our branch up to date, the merge command is something like:
merge http://.../project/trunk@LAST_REBASE http://.../project/trunk@HEAD ./branchWC
The script then bumps up the 'lastrebase' property and commits.

Our deliver scripts require that you have just rebased your branch before running the deliver script, so the only difference between your branch and the trunk are the changes you made. The deliver script doesn't do a merge based on revision ranges because if it did, the range would include some commits to the branch that were done by the rebase script, and so changes that were done on trunk, and merged into your branch, would be re-merged into trunk. I think this is the reason why suggestion #1 wouldn't work for us, but if I'm mis-understanding it, let me know.

Thanks
Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on 2008-02-01 15:52:07 CET