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

Re: Cherry-picking merges

From: Vadym Chepkov <vchepkov_at_gmail.com>
Date: Thu, 29 Apr 2010 07:17:06 -0400

On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote:
>
> [b2]$ svn merge --dry-run ^/branches/b1
> --- Merging r2 through r4 into '.':
> C README
> Summary of conflicts:
> Tree conflicts: 1
>
>
> After r3, you'll need to do a '--record-only' merge of r4 into the second branch:
>
> (untested) svn merge --record-only -c 4 ^/branches/b1
>
> SVN doesn't seem to trace back through the commits to see that r3 was really a merge from b2->b1. Like yourself, I initially though that it would be able to deal with this, but it doesn't seem to (and there is probably a very good reason why it can't).
>
> Cheers,
> Daniel B.

Well, as you can see in the log, it also wants to merge r3 back, not just r4, so we would have to "record-only" 2 of them, it seems.
The problem is, we utilize a "home made" automerge utility that constantly merges all changes from b1 to b2,
but merges from b2 to b1 are done manually. After r4 is committed, it produces conflict for automerge immediately and this is what I am trying to avoid. By the way, maybe there is an intelligent automerge utility out there that can handle this kind of things, if anyone knows.

Thanks,
Vadym
Received on 2010-04-29 13:17:42 CEST

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.