Server-side vs client-side merge

[stevea]

Hello all,

My company uses developer branches. We merge any changes on trunk into our branches regularly, then merge our developer branch's head onto trunk's head when we want to deliver our changes. Our practices are quite like Feature Branches described in the svn book

Our branch->trunk merges are slowing down on some larger projects, and I'm wondering how the merge actually happens. We've got a working copy of trunk and of our branch, they're both committed and fully updated, but it doesn't look like I can use those working copies for the merge comparision. According to svnbook it looks like, if you specify working copies instead of URLs, it just uses those WC's as an 'anchor' and gets the URLs from there, after which it gets all the files from the server for doing the compare.

I'm confused about how this is actually happening. Wiresharking the traffic shows me that it's downloading some (maybe all) of the files needed to compare. So is it taking the worst of both choices (server-side and client-side) and downloading new copies for everything before comparing?

Since I've got up-to-date WC's of both trunk and branch, why can't I do:

merge ./trunk ./branch ./trunk

and have it do the comparison between the WC's, and apply the changes to ./trunk?

Any insight on how this works would be appreciated, or general advice on how to debug the slowdown or improve it.[/code]

[andyl]

What Subversion does is in part dependent upon what you tell it to do (i.e., the exact parameters passed to the program).

Generally, one should consider a merge as you're doing it to be "calculate the diff between these 2 revisions on this URL, and apply it to this WC." You shouldn't need a WC of your branch to merge the branch into trunk - just the trunk WC. I'm puzzled as to why you're doing the merge with 2 different paths. The following should be sufficient:

[code]svn merge -r REV_WHERE_BRANCH_MADE:HEAD URL_TO_BRANCH PATH_TO_TRUNK_WC[/quote]

That's really what you want, right? To apply all changes which have been made to the branch, to the trunk. Diffing trunk against branch may work for now, but some information may be lost, like history when files are copied/moved/renamed. Doing it the way you're doing it I think will generate a delete then add without history when a file is moved.

[stevea]

The way we're doing it, it only generates a delete+add if the file on the branch doesn't a have common ancestry with the file on trunk.

The reason we 'deliver' our changes to trunk this way is because we keep our branches up to date from trunk using the normal way you're describing:

svn merge -r LAST_UPDATE:HEAD TRUNK_URL BRANCH_URL

With this method, people can work on updates for a while, keeping up-to-date with trunk, but not deliver their changes to trunk until they're done. The problem is that all the changes made to the branch since creation would include all the merged-in changes from trunk, so we do the delivery by comparing HEADs in trunk and the branch.

The main problem/question I have, however, is where do the files come from that are compared for a merge? If I specify two working copies to compare, does it use the files of those WCs? Or does it just do an 'svn info' to get the url from those WCs, then gets all the files from the server.