views:

2903

answers:

4

I have what I thought was a simple scenario - using TortoiseSVN:

1) I made a branch (B2) of an application (to work on implementing image sprites & JAWR).

2) Testing & development went on as normal on the trunk.

3) I re-based the branch a couple of times over the last few days by:

3.1) Merged trunk (by range of revisions) to my branch-b2 working copy, resolving conflicts during the merge.

3.2) (after testing branch-b2), I commit the re-based branch-b2.

This all worked as I expected. But merging the branch back into the trunk is having its way with me:

4) After all updates committed in branch-b2; I make sure I do an SVN Update on trunk and branch-b2.

5) Then, I try to merge (range of revisions) from branch-b2 into the trunk. However, for any new file that had been added to the trunk, and subsequently added to branch-b2 when I rebased it, I get a tree-conflict. I'm not sure what the proper way is to resolve these conflicts.

The most typical advice I've seen is to either delete the tree-conflict files from the trunk, then merge the branch over; or delete the entire trunk, copy the branch files over, and then commit them as a new version in the trunk. Neither of those options seems like a good idea- first one is a pain, and both seem like they would lose file revision histories.

What'd I do wrong, and how do I fix it?

+9  A: 

Sounds like you're using the pre-1.5 merge style and trying to reintegrate the branch into trunk. In that case, what you want to do is first ensure all the trunk changes have been merged in to the branch, and then instead of range-merging the branch to a working copy that points to the trunk, you want to merge "FROM trunk@HEAD TO branch@HEAD" with the working copy pointing to trunk. In essence:

"Give me all the changes I'd need to make trunk identical to branch".

This works if you've already merged all the trunk changes to the branch, because then the only difference between trunk and branch are the changes made in the branch.

Make sense? :)

Rytmis
That makes sense - will give it a shot first thing in the a.m. Out of curiosity and a desire for sanity in the future, what's the post-1.5 merge style?
mitch_moop
1.5 and onwards you can skip the revision range in the first merge and use something like "svn merge --reintegrate branch" for the second merge (can't recall the TSVN gui specifics). On the downside, after reintegrating you'll have to re-branch because the reintegrate does something funny to the mergeinfo.
Rytmis
Thanks @Rytmis, I just managed to pull this off, but I want to offer a translation for Tortoise users.1) Switch your working copy to the branch (if it isn't already)2) Right-click working copy, TortoiseSVN > Merge > "Merge a range of revisions", click Next3) URL to merge from = Trunk, click Next, Merge4) Switch working copy to Trunk5) Right-click working copy, TortoiseSVN > Merge > "Merge two different trees", click Next6) From: Trunk (use HEAD revision) To: Branch (use HEAD revision)7) Click Next, Merge.8) Commit your working copy.DONE
whatispunk
A: 

Hi. I investigated the same problem. It is "feature" in Tortoise SVN 1.6.5. TortoiseSVN 1.5 works fine with our repositoty (SVN 1.5). TortoiseSVN 1.6.5 when rebasing adds files from mainline as NEW (without saving merge-history).
And reintegrating branch resuls in treating those files as conflicting with mainline.

I solved the problem by using feature of TortoiseSVN 1.6 "reintegrate branch". It's specifically purposed for feature-branches.

-- Alexey Korsun

A: 

I could not really figure out how the above solution was to work so my work around is different. First I made sure the branch contained all the changes from the trunk.

1)I got a fresh copy of the trunk. 2)I exported the branch to a temporary location using the tortoise svn export. 3)I used windows explorer to copy the entire branch tree over to the trunk and overwrote all files 4)I used the check for changes command on tortoise and included all unrevisioned files checkbox. 5)I selected all the files and clicked add.

You should use solutions that have not been built so the unrevisioned files do not include output.

I cant wait until we upgrade to 1.5+

Starkman
A: 

Starkmans solution helped me. +1. ( Export the branch files, overwrite the trunk files with it, check for changes with unversioned files, add the non-versioned files and commit everything. )

I simply don't understand what the problem is about. Nothing else seemed to helped. Subclipse hanged on this and never finished, Tortoise did not crasch (but would not merge of course and the resolving thing did not seem to work at all).