On Tue, Apr 29, 2008 at 11:23:49AM -0400, Mike Todd wrote:
> Here's the scenario: we have our trunk, and a dev branch which was created
> from revision 300 of the trunk. Sometimes we'll find a bug, fix it on
> trunk, and want to merge that fix back into dev, when that same file has
> also changed on dev. Here's the commands we run:
>
> cd branches/dev
> svn merge -r300:HEAD http://svn.example.org/foo/trunk/file.php file.php
Which version of Subversion are you using?
And wouldn't you usually just merge the revision the fix was made in?
In 1.4, your command tries to merge *all* changes made to file.php
on trunk since the branch point into your branch, *every time* you
run your merge command! You are repeatedly telling Subversion:
"Make a diff between trunk/file.php at r300 and how it looks now,
and apply that diff to file.php."
In 1.5, your command would only merge changes that have not been
merged into your branch yet, but you will still merge all changes
ever made to file.php on trunk into your branch. Contrary to 1.4,
each change will only be merged once, thanks to merge-tracking.
Merge tracking remembers which revisions that modified trunk/file.php
have already been merged into the branch. You are telling Subversion:
"Take all changes made to trunk/file.php from r300 and how it looks now,
and of those, apply only the changes which have not yet been applied
on my branch to file.php."
What you probably want instead is something like:
"Pick the particular change I made in r344 that fixes a bug in
trunk/file.php, and apply it to file.php."
That works like this:
svn merge -r344:345 http://svn.example.org/foo/trunk/file.php file.php
or (a shorthand with the same effect):
svn merge -c344 http://svn.example.org/foo/trunk/file.php file.php
That's how we merge bugfixes into Subversion's release branches, anyway.
> However, this results in a conflict, and when I open branches/dev/file.php,
> it shows the entirety of the dev version, =======, then the entirety of the
> trunk version below that. Even though in the test case I ran just now, the
> files are exactly the same other than one line added to dev, and one line
> (in a different place) added to the trunk version.
That is odd. I'm not sure what could cause this. The only thing that
comes to mind would be that both files had different amounts of
whitespace on every line. But there may be an obvious reason for
this that currently escapes me. It may have to do with the giant
revision range you are specifying while merging, but I'm not sure.
> Is there any way to merge the change from the trunk
> back to dev, when both files were changed (in different places), without it
> creating a conflict?
Yes, by specifying only the exact revision (or revisions) you want
to merge (see above).
--
Stefan Sperling <stsp_at_elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
- application/pgp-signature attachment: stored
Received on 2008-04-29 17:59:46 CEST