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

RE: More Merge Bad Behavior

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Fri, 14 Nov 2008 18:20:30 -0500

My understanding is that you can not do this. I asked about it here and
no one really answered me.

If you create a branch and you want to merge changes made in the branch
back into trunk automatically then you need to merge into the branch
from trunk:

In the branch workingdir:

svn merge http://path/to/trunk

Then in the trunk workingdir:

Svn merge --reintegrate http://path/to/branch

Then you are supposed to delete the branch... because if you try to
merge back in you could have problems.

All the above supports what they call a feature branch.

However, if you branch for a release (as we do) and you want to merge
back changes made in the branch to the trunk there is no auto way to do
this and the merge isn't tracked. You have to do specify the from-to
something like:

Svn merge http://path/to/branch@300 http://path/to/branch@322

Also, that merge isn't tracked in any way so you have to remember or log
that you have merged up to 322 in case you want to merge future changes
in the branch.

Now, this is the way I read the book and my testing has gone. If there
is any way to do this that merge tracking takes care of I would love to
hear that I am wrong.

BOb

-----Original Message-----
From: Rush Manbert [mailto:rush_at_manbert.com]
Sent: Friday, November 14, 2008 5:45 PM
To: subversion
Subject: More Merge Bad Behavior

I posted a few days ago about my problems merging either to a branch
from the trunk or from that branch back to the trunk.

Now a colleague is seeing the same problem.

He copied the trunk to a branch 3 days ago. We have been making
changes on the branch since then, and now we're finished. In the
meantime, some non-overlapping changes happened in the trunk. Now he
wants to merge the branch back into the trunk. Since he never needed
to synch changes in the trunk by merging, we don't need to do a
reintegration merge, so he tried this:
* Check out the trunk to ~/trunk_merge
* cd ~/trunk_merge
* svn merge URL_TO_BRANCH

Svn thinks about this for a while, then says it wants to merge
revision 2 through 1633 to the WC. The branch was created at revision
1634.

This wants to do all sorts of crazy stuff, so we killed it, ran svn
revert -R ., then svn stat to be sure we had a pristine WC.

Then we tried this merge command:
svn merge URL_TO_BRANCH -r1634:head --dry-run

The output from this looks like it would do the right thing.

This is the second time now that the merge wants to merge everything
from the beginning of the world (rev 2) through the revision just
before the branch was created (rev 1633), and we don't understand why
this is happening. We thought Subversion 1.5 was supposed to track the
revisions correctly so that this would work without needing us to
specify the revisions.

We are running the 1.5.1 client, and the server is running 1.5.0. We
created both branches using SmartSVN 4, which is a SVN 1.5-compliant
client.

We have also done a very similar merge in the past (2 months ago), and
it worked as expected.

We're sort of at a loss here. My colleague suspects there is something
wrong with our repository. I said I would post again and see if any of
the experts had some advice. Something we can look at on the
repository, or the branch, or ??? Any guidance would be appreciated.

- Rush

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-15 00:20:53 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.