[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: Rush Manbert <rush_at_manbert.com>
Date: Fri, 14 Nov 2008 15:53:10 -0800

Hi BOb,

Replies inline.

On Nov 14, 2008, at 3:20 PM, Bob Archer wrote:

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

Well, the 1.5 version of the book says this:

If you're using svn merge to do basic copying of changes between
branches, it will generally do the right thing automatically. For
example, a command such as the following:

$ svn merge http://svn.example.com/repos/calc/some-branch

will attempt to duplicate any changes made on some-branch into your
current working directory, which is presumably a working copy that
shares some historical connection to the branch. The command is smart
enough to only duplicate changes that your working copy doesn't yet
have. If you repeat this command once a week, it will only duplicate
the “newest” branch changes that happened since you last merged.

Here's the URL:
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.advanced.advancedsyntax

> 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
>

This was what originally did not work for me.

> 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

I think this is the equivalent of what we finally did:

In a clean checkout of the trunk:
svn merge URL_TO_BRANCH -rBranchCopyRev:head

which forced SVN to get the correct revisions.

>
>
> 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.

 From what I read, it sounds like I should be able to do any of the
things I have tried.
I guess I need to do some specific testing and see if I can figure out
what's going on here...

>
>
> BOb

Thanks for your reply.

>
>
>
>
> -----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:53:31 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.