Rectifying a foobar split/merger
I have foobared the branch and cannot merge it anymore. The main trunk is the next release; the branch (v0.9.4) is the current code in which I am fixing bugs and releasing point releases, like v0.9.4.1, v0.9.4.2, etc. I believe where I made mistake here: When I release code, I tag the v0.9.4 branch to the specific version. Then when I did a few of the merges, I merged the tag, not the v0.9.4 branch. Now the new things I have had to add, say in tag v0.9.4.3 I added a file, now it always comes up with a conflict. I am assuming that is because now that I am at tag v0.9.4.7, subversion isn’t able to figure out the connection between the two tags. On the other hand, it is my theory that if I had simply always merged in the branch, there wouldn’t be an issue. Things have gotten worse now that I have added a new folder. Is there some way to reconcile this? Sam
Re: Rectifying a foobar split/merger
On Mon, Jun 14, 2010 at 4:35 AM, Cooke, Mark wrote: >> -Original Message- >> From: scarle...@gmail.com >> Sent: 14 June 2010 01:19 >> Subject: Rectifying a foobar split/merger >> >> I have foobared the branch and cannot merge it anymore. The >> main trunk is the next release; the branch (v0.9.4) is the >> current code in which I am fixing bugs and releasing point >> releases, like v0.9.4.1, v0.9.4.2, etc. I believe where I >> made mistake here: >> >> When I release code, I tag the v0.9.4 branch to the specific >> version. Then when I did a few of the merges, I merged the >> tag, not the v0.9.4 branch. >> >> Now the new things I have had to add, say in tag v0.9.4.3 I >> added a file, now it always comes up with a conflict. I am >> assuming that is because now that I am at tag v0.9.4.7, >> subversion isn't able to figure out the connection between >> the two tags. On the other hand, it is my theory that if I >> had simply always merged in the branch, there wouldn't be an issue. >> >> Things have gotten worse now that I have added a new folder. >> Is there some way to reconcile this? >> > I think you need to look at the --record-only option: > > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn > .branchmerge.advanced.blockchanges How would I go about using --record-only to solve my problem? Here is my thought: Currently the v0.9.4 branch is r1087, the trunk is r1085. 1: Manually copy over all the changes from the current v0.9.4 branch to the trunk and check in the truck, making revision 1088. 2: Next time I do a merge from the branch to the trunk, I use the --record-only to copy over starting at r1085. Is that correct? How does one to a --record-only from TortoiseSVN? Sam
fixing foobared merge with --record-only
I have foobared the branch and cannot merge it anymore. The main trunk is the next release; the branch (v0.9.4) is the current code in which I am fixing bugs and releasing point releases, like v0.9.4.1, v0.9.4.2, etc. I believe where I made mistake here: When I release code, I tag the v0.9.4 branch to the specific version. Then when I did a few of the merges, I merged the tag, not the v0.9.4 branch. Now the new things I have had to add, say in tag v0.9.4.3 I added a file, now it always comes up with a conflict. I am assuming that is because now that I am at tag v0.9.4.7, subversion isn't able to figure out the connection between the two tags. On the other hand, it is my theory that if I had simply always merged in the branch, there wouldn't be an issue. Things have gotten worse now that I have added a new folder. When I asked about this a week or so back someone suggested I use the --record-only option. How would I go about using --record-only to solve my problem? Here is my thought: Currently the v0.9.4 branch is r1087, the trunk is r1085. 1: Manually copy over all the changes from the current v0.9.4 branch to the trunk and check in the truck, making revision 1088. 2: Next time I do a merge from the branch to the trunk, I use the --record-only to copy over starting at r1085. Is that correct? How does one to a --record-only from TortoiseSVN? Sam
