This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In my group, I have the unenviable task of merging changes from one branch into another. It "appears" that occasionally, Netbeans doesn't "see" these changes. This happened today: We have two branches, B1 and B2. There were a few changes to source files in B1 and I was asked to merge those changes into B2. I did the following (which is always my "procedure"): 1) I opened my B1 project in Netbeans, did a CVS Update and clean/build - just to make sure everything was fine. 2) I then marked all the files in B1 with tag T2. During a previous merge, I had marked the files with T1. 3) I then closed project B1 and opened project B2 (I know there's a "switching to branch" capability, but I don't feel safe doing that). 4) I go to the root node of my project and right-click CVS->Merge Changes From Branch. The merge dialog pops up. 5) For "Starting From:" I pick Tag/Revision: T1. 6) For "Until:" I pick Tag/Revision: T2. 7) I hit "Merge". It finds a bunch of file changes and merges them. It finds a few that it can't merge automatically and lets me resolve the conflicts. I do. I commit all changes and tell people all is well. 5 minutes later, a developer asks why one of her changes in B1 weren't merged in :-( I try to go to that specific file and do steps 4-7 on it. Nothing. I look into the B1 and B2 source directories and do a UNIX diff on that file - sure enough, they're different. I ask my Eclipse-toting buddy to do the Eclipse equivalent to see what he thinks has changed. He, of course, sees that that file has changed. I went back to the IDE and inspect what CVS tags are on that file - and notice that this file has no T1 tag! Could that be the cause of the problem? (But, then, why did Eclipse discover the change with the same two tags??) Anyway, I figure if it doesn't have the T1 tag, let's just pick the branch point as the "From:" on the merge - this way all changes on branch B1 would be considered for the merge. But, again. NB doesn't see any changes. I exited the IDE, suspecting that it's instability of a nightly build. Went to my trusty 6.5.1 version - even removed $HOME/.netbeans and repeated the above. Still nothing - Netbeans refuses to admit that this file has changed! I gave up. I needed to commit the changes because I was under time pressure. Five minutes after announcing the faux-pa, my manager replies to my e-mail with "When are you moving to Eclipse?" This has happened before - but this is the first time that I caught it early enough to do the above research - usually, I find out several days later from some developer: "hey, I thought you did a merge a few days ago - where are changes in file X and Y?" I would usually answer: maybe the files had a merge conflict and I accidentally made the wrong choices during conflict resolution - sorry dude!" But this time, I was able to see that the file wasn't even marked as a changed file! I marked this as a P1 because this problem can have pretty bad consequences: if QA doesn't do a regresssion in B2 on all the bugs fixed in B1, they may never find that bugs are being re-introduced! I'm not sure how I can help further: as I said, I had to fix the problem manually because of time pressure so now, of course, the two branches are in sync :-(
After spending a long time trying to reproduce your problem I finally succeeded. The basic reason for this to happen is indeed the missing 'T1' tag on that file. Merge command in Netbeans operates similarly to a command line cvs client, it passes T1 and T2 as arguments (with -j option) to a cvs update command. Since the file is not tagged with T1, the 'cvs update' won't succeed and in my case response with: 'file XXX exists, but has been added in revision T2'. So the way you are trying will not work even in a command line (could you check it yourself? try 'cvs update -j T1 -j T2 FILENAME'). So if there's no way even for the command line client to handle this, I think we should look for a workaround and rather consider this as an ENHANCEMENT than a BUG. About Eclipse: I tried the same scenario in Eclipse and there's a slight difference. Eclipse seems to use two ways to accomplish this. In the merge dialog you can select either 'Preview the merge in the synchronize view' or 'Perform the merge into the local workspace'. When I select the latter, it results in the same problem - the file is not merged and the command responds with 'file XXX exists, but has been added in revision T2' The first option (Preview the merge in the synchronize view) opens a synchronize view and allows you to merge manually. It does not seem to perform merge but detects its state in B1 and B2 and lets you merge the changes by yourself. Back to Netbeans: There's a way to detect unmerged files in IDE. If you look in the Output window, there's a tab with all cvs commands output. If you perform a merge, the tab is filled with merge command's messages. If you spotted any messages as: 'cvs update: file XXX exists, but has been added in revision T1' you can probably find those unmerged files. Then you need to identify the last merged revision (e.g. from the Search history) and fill this as a start revision in the merge dialog. I understand this is far to difficult to use, but currently i don't see any other way. Please, could you: 1) check if the file can be merged with the command line client - 'cvs update -j T1 -j T2 file' - and report back the output of the command 2) look at the output tab in IDE (the one with cvs messages) and check if there's a message as 'file XXX exists, but has been added ...' or any other messages related to the file 3) could you please tell, what option in the merge dialog you selected in Eclipse? 4) Do you have any idea, why the file has lost the original tag? Maybe there's an issue with the tag command in Netbeans and the file wasn't tagged the last time you merged. I would see this as a more serious than the failing merge which can't be performed even with the command line client. 5) Could you please check where the file was originally created? (TRUNK, BRANCH1, BRANCH2, ...) Thenks
Any update on this?
Without requested information for long time - INVALID. We can't do anything in this case. Reporter, please add requested information and reopen issue. Thanks in advance.
@ppis, Sorry I didn't respond to ovrabec's request for verification. Yes, it's exactly what he determined. I am changing this bug into an Enhancement bug so that an improvement can be considered in the future.