Merging trunk to branch

views:

162

answers:

+2 Q:

Merging trunk to branch

This is the first time trying to merge the latest in the trunk Head to my branch. I just want to get any latest updates from other developers on my team into my branch. I am using Subversion 1.6.7. So in the Merge dialog I selected the option "Merge 2 different trees".

My question is this:

My branch's latest revision is 358 and the mainline trunk is 357. So when I do a test merge, it deletes anything new in 358 (my branch). Should I be going from my trunk to branch instead of from branch to trunk in this case since my branch has a higher revision number? I know in the examples on various blogs, they say to go FROM branch TO trunk but in my situation the branch has the higher revision number.

alt text

Now during the test merge, I don't see why it's deleting those files that don't exist in my trunk (that I had added new to my branch during development):

alt text

Now lets do the reverse...which is how I think it should go (Because then I'd be going FROM a revision that's lower (357) TO a revision that's higher (358). So here it is going FROM mainline trunk TO my branch:

alt text UPDATED AFTER COMMENTS BELOW:

Ok, so when I try trunk-to-trunk, here's what I get:

alt text

+2 A:

I don't think you're selecting the right URL to merge into. You should right click on the branch you want to merge into, select merge, and then select two revisions along the "trunk" branch from which to merge.

Ken Liu 2010-02-24 19:55:12

I am right-clicking my branch folder and selecting merge so it is correct. I just don't understand why in the merge test dialog that it appears to be adding/updating all the trunk changes but then deletes any new files that I had added in my branch that do not exist in the trunk. Why is it deleting new files that I had created in my branch? It shouldn't be touching those and only be adding changes (adding files that exist in trunk but not in my branch yet) or merging changes (merging new changes from trunk files to the same files that exist in my branch).

CoffeeAddict 2010-02-24 20:04:59

My working copy IS my branch and that's what I right clicked on to get the above. I changed the TO to be my trunk in the merge dialog.

CoffeeAddict 2010-02-24 20:06:10

both the TO and FROM fields should be trunk revisions, otherwise you will get strange results. I think you want FROM = 344 and TO = HEAD

Ken Liu 2010-02-24 20:21:44

to clarify: FROM http://...trunk, rev 344 TO http://...trunk, HEAD or 357

Ken Liu 2010-02-24 20:30:46

just weird. Trunk to trunk. I guess it's not as intuitive as one thinks because my mind says from branch to trunk because you're going from one point in time to another.

CoffeeAddict 2010-02-24 20:33:38

I've updated with a screen shot of our repo

CoffeeAddict 2010-02-24 20:38:57

yeah. visualize it this way: when you right-clicked the branch, you told Tortoise which branch you want to merge INTO. The "Merge" dialog then is used to pick two points along _the branch you are merging from_. The TO and FROM fields are the two points along the line. If you think of the trunk as just another branch, it makes sense.

Ken Liu 2010-02-24 20:39:38

also, I can't specify trunk to trunk. That would mean that I would be having a trunk under my branch folder which I do not have. I only have a trunk in the mainline project.

CoffeeAddict 2010-02-24 20:49:44

no. if you want to get changes that are being made in the trunk and then merge them into your branch, then you have to select two revisions along the trunk...did you try what I suggested?

Ken Liu 2010-02-24 21:04:44

see updated post per your last comment.

CoffeeAddict 2010-02-24 21:21:23

nothing changed between revisions 357 and 358. you want 344-357.

Ken Liu 2010-02-24 21:28:07

true, I verified this by going back a few revisions (which I should have done anyway). I needed to start from 344... since that was the last revision I was at for mainline trunk before I had branched out.

CoffeeAddict 2010-02-24 21:36:02

yup, you got it! (note that I said this 7 comments ago...) you can see from the revision graph that rev 344 was the revision where your branch started.

Ken Liu 2010-02-24 23:05:04

you know, it would be nice if you would accept the best answer when so many people helped you out with this problem

Ken Liu 2010-03-26 03:28:09

+2 A:

Should I be going from my trunk to branch instead of from branch to trunk in this case since my branch has a higher revision number?

The revision number shouldn't determine whether you go from trunk to branch or vice versa. What is important is: what do you want to merge? Do you want to move the changes created in the branch back to trunk, or do you want to move changes from trunk to the branch?

If you want to move changes from the branch to the trunk (which is usually what you want, if you are using branches for "what they are intended for") then merge from the branch, r345 - 358 into trunk. Otherwise, do it the other way around.

EDIT: What you are doing in the screenshot above is taking the delta FROM rev 358 TO rev 357 and merging this into your working copy. Since you added files in commit 358 and 357 - 358 < 0, the delta will do the opposite operation, that is, removing the files.

Rune 2010-02-24 20:05:34

move changes from trunk to the branch

CoffeeAddict 2010-02-24 20:11:38

Thanks. I don't know what delta means as it pertains to subversion. I only know rev #s. So what do I do to keep from the deletion of those files in my branch?

CoffeeAddict 2010-02-24 20:12:30

Delta just means that what you are saying to SVN is: take whatever changed between revisions 358 and 357 (a "delta" is a change in something) and apply that change to my working copy. Since 358 has files that 357 don't, the change from 358 to 357 is effectively that files were removed.

Rune 2010-02-24 20:16:57

In the screenshot above make sure you have the url of trunk in both textboxes. In the "from" region set rev == 357 and in the "to" part set rev == 358, then tell it to merge this into your working copy.

Rune 2010-02-24 20:18:29

Ok but then you're going to have that case a lot of times on a team whereas if you're adding new files to a branch, quite often it could be that ups the revision to a higher number overall in the repo that the last revision to trunk. So then what do you do? You don't want your stuff to be wiped away like that just because you had more submits lately to your branch than did the trunk at any given point in time that you desire to update your branch with trunk changes.

CoffeeAddict 2010-02-24 20:28:56

so you're saying that the merge is trunk/branch independent and that it's only looking at merging by revision numbers and it doesn't care whether it's trunk or branch? I know in the merge options, that's where you decide whether you're merging to branch or trunk. So you're saying before that, that you should make them both trunk and therefore it's only looking to merge revision numbers and that's all it really cares about?

CoffeeAddict 2010-02-24 20:30:46

Oh, by the way, Tortoise is a bit weird when it comes to ranges and whether it includes the end points or not, so if having from = 357 and to = 358 doesn't produce a result, try setting from = 356 (and, obviously, do a test run first :-)

Rune 2010-02-24 20:31:18

this is so God damn confusing. I know Subversion and Tortoise together can do a lot but man, it's a royal pain to figure out exactly how this works.

CoffeeAddict 2010-02-24 20:32:15

I've updated with a screen shot of our repo

CoffeeAddict 2010-02-24 20:39:27

Maybe think of it this way: let's say you put the trunk url in both boxes and r. 10 in the "from" field and r. 20 in the "to" field (I'm just making these numbers up). Then what you are saying to SVN is: "Create a script (a "patch" in SVN lingo) that, when applied to the content of r10 will make the content identical to r20. Then apply that script to my working copy". Thus, in your example, you would be saying to SVN: "create a script that makes r. 357 identical to r. 358. Then apply it to my working copy". Since going from r357 to 358 adds files, so will applying the script to your work. copy

Rune 2010-02-24 20:41:19

but my problem it it's deleting files! it's deleting some new files I had added to my branch..because hey did not exist in the mainline trunk.

CoffeeAddict 2010-02-24 20:47:23

It is deleting the files because you are saying "create a script which will take me FROM 358 TO 357", so you are essentially telling it to go back in time :-). Just tell it to go FROM 357 TO 358. Remember, here you are not telling it where to apply the changes (that will be to your working copy), you are telling it where to start picking up changes and where to end. Don't let the "from" and "to" in the screenshot fool you: it says nothing about where the changes will be applied (or "moved to"). Think of is as a timespan: "I want to move what happened in trunk from r357 until r358".

Rune 2010-02-24 20:54:04

right. I get that. But if I change then the opposite in that merge dialog and go FROM trunk TO my Implementation folder (branch folder) then I get a bunch of tree conflicts. Is that normal?

CoffeeAddict 2010-02-24 20:57:35

You need to have the trunk URL in both the "From" and "To" textboxes, 357 in the "From" Rev box and 358 in the "To" Rev box. In that way you are saying "I'm interested in what happened from r357 in trunk until 358 in trunk". Even though it is possible, it usually does not make sense to put different URLs in the "From" and "To" textboxes.

Rune 2010-02-24 21:02:15

oh so it's like saying take what changed in trunk (revision 357 to 358) and since I had right-clicked the branch to select the merge tool in the first place that it will take those changes from trunk (rev) to trunk (rev) and add them to the folder that I had right-clicked on (done a merge on). Maybe that way I can finally understand this.

CoffeeAddict 2010-02-24 21:12:27

Seems like this article (done in a way older version of Tortoise) is no longer really valid much: http://weblogs.asp.net/bsimser/archive/2008/05/06/day-to-day-with-subversion.aspx

CoffeeAddict 2010-02-24 21:13:16

Yeah! What you said above is absolutely correct :-). When you have done the merge, you commit your working copy (which will commit it to branch) and in that way you have moved your changes from trunk to branch.

Rune 2010-02-24 21:16:09

Thanks, NOW I get it. But check out the updated post. I tried the trunk-to-trunk. Either it worked without any merge conflicts OR I did something wrong because I don't see any "added" or "merged" in the test merge dialog after trying trunk-to-trunk.

CoffeeAddict 2010-02-24 21:22:32

Ah, sorry, my bad, I've messed up the revision numbers all along :-(. Since no files were added to trunk between r. 357 and r. 358 the merge is empty. What did you want to do? If you want to move all changes made to the trunk after the branch was created, you would merge the range trunk(344) to trunk(357).

Rune 2010-02-24 21:29:32

right, I needed to start from 344... since that was the last revision I was at for mainline trunk before I had branched out.

CoffeeAddict 2010-02-24 21:37:02

Perfect. Please tell me if everything works out.

Rune 2010-02-24 21:37:56

This turned out to be a pretty long-winded discussion. Would you mind marking it as accepted if it helped you, so that others don't have to try it all out for themselves? Otherwise, please mark another answer as accepted.

Rune 2010-03-18 22:21:51

+3 A:

Tortoise merging is very good, but there's a trick to it you have to know.

When merging, firstly use the top radio button option (merge a range of revisions) and always merge into the destination. So, right click on the destination working copy, select merge, then edit the url in the merge dialog so the From: field contains the branch you want to take changes from.

Its a bit backwards when you first see it, but it actually makes more sense once you've understaood what's happening - that you're taking all the changes in the url on the merge dialog, and applying them to your working copy. That's the trick top understand - you're not merging the files (like you would manually) but you're re-applying the changes that were made to the source branch.

Use the 'show log' button to select the revisions you want. If there is mergeinfo (ie previously merged revisions) they'll show as grey.

The other part of all this is that SVN isn't too good on handling tree conflicts - if you've added or deleted a directory, SVN will ask you what you meant to happen (ie a tree conflict). All you have to do is resolve the directory and select the ones that actually were deleted or added. It does this because it cannot be sure a file was deleted (or added) or just renamed.

I merge all the time now, its really easy, but I don't think I've ever used the other 2 merge options on the first dialog. Alwyas merge from the url to your working copy, once the merge is complete you can review the results and commit them once you're happy.

gbjbaanb 2010-02-24 20:12:41

well, I wouldn't have thought to pick the "range of revisions" but I guess that makes sense because you're essentially merging 1 or more trunk revisions into your branch.

CoffeeAddict 2010-02-24 20:17:27

So now I'm confused as to which option to use because it seems to me like that last option (the one I am using) is the one that's mean to do merges like this with

CoffeeAddict 2010-02-24 20:20:19

It would be nice if the freaking documentation for Tortoise would explain possible scenarios and have some good tutorials on this subject. Some real-world examples (merge trunk-to-branch, yada yada). I have seen nothing that relates to merging in their docs outside of just using the merge tool for looking at what's changed. It's just amazing that this being a very seasoned open source project that this is not in there somewhere to explain this stuff more in the real world.

CoffeeAddict 2010-02-24 20:20:58

I've updated with a screen shot of our repo

CoffeeAddict 2010-02-24 20:39:44

it doesn't matter which option you choose, just pick one that works :)

Ken Liu 2010-02-24 21:00:40

@gbjbaabn: Tortoise offers a reverse merge option, that may allow you to go the other way

Casebash 2010-07-09 03:05:15

If your intent is to just merge all trunk changes to your branch that aren't already there, you shouldn't need to specify a revision range at all (explained after the steps)

I believe this should be your workflow:

Right click on a clean (no modifications) working copy of your branch
Select 'Merge a Range of Revisions' and hit Next
Fill in 'URL to merge from' with the URL to trunk and hit Next (do not fill in the revisions field)
... test merge or do the merge.

Since you're on 1.6, which is a version of Subversion with merge tracking, not specifying a revision range will use Subversion's merge tracking and will merge any revisions that aren't already marked as merged in the branch.

If this is the first time you've merged anything from trunk to the branch, that means anything from the revision after the one you created your branch from through the HEAD revision of trunk will be merged into your branch workspace, and then when you commit that merge will be recorded. If you decide to sync your branch again a week later, using the same steps it would only merge any revisions in trunk that weren't merged previously.

Joshua McKinnon 2010-02-24 21:01:58

when you say a clean branch, do you mean after I checked in the latest to my branch or do you mean get latest (Fresh) to a new directory (new workspace) of my branch?

CoffeeAddict 2010-02-24 21:24:42

a fresh working copy of your branch, or at least one with no uncommitted modifications. (if you do 'show modifications', nothing should come back).

Joshua McKinnon 2010-02-24 22:07:45

ansaurus

tags:

views:

answers:

Merging trunk to branch

related questions