Community
Participate
Working Groups
Build ID: 3.2.2 Steps To Reproduce: I create a repository with the CVSNT server. After this I create two naïve projects LE_Module1 and Module1. The former is a Library project and the latter is a Module Project. The next step is to share the projects. I select the share option, I choose the repository and I enter the module name. The repository has LEModule1 in the HEAD branch. After this, I do the same process with the other project. Now both projects are inside the HEAD branch. The following step is to create a new branch and to put the projects in. We use Team->Branch. Next, we set the name of the branch.Now both Projects in branch HEAD and only LEModule1 in branch BRANCH1. At his point we can see our problem. If we do the "tag with existing" operation on LEModule1 branch BRANCH1 is displayed. If the same operation is done on Module1 no branches are displayed. In other version of the WID, we can perform this operation with other output. The version is IBM WebSphere Integration Developer Version: 6.0.2 Build id: 6.0.2-20061204_1400 The difference between this version and the other is that branch BRANCH1 is showed. When we perform a "tag with existing" on Module1 and branch BRANCH1 both projects are in HEAD and BRANCH1 branches. What we have do with version 6.02 we want to do with version 6.1 as well. More information: This bugzilla is being opened for a customer using WebSphere Integration Developer (WID). Both versions of WID are based on Eclipse 3.2.2 Comparing WID 6.0.2 and 6.1.0 we have found out that the difference appears during the "new branch operation": When you perform "Team-Branch" command for a single module WID 6.0.2 creates a populated branch folder for it as well as an empty (skeleton only) branch folder for another module. The behavior is much different in WID 6.1.0 where "Team-Branch" command ends up with only one populated folder for the module selected. Consequently customer encounters different experience in subsequent "Tag with Existing" operation applied on the another module. Customer has been stopped at the migration of WID 6.0.2 to 6.1.
Hello. There has been no movement on this issue. Can you provide an update regarding your investigations?
Hi Brian, I haven't looked at the issue for some time. (In reply to comment #0) > More information: > This bugzilla is being opened for a customer using WebSphere Integration > Developer (WID). Both versions of WID are based on Eclipse 3.2.2 That's not quite true. AFAIK 6.0.2 is based on older version of Eclipse (3.2?). I tracked changes made to the branch operation between those two versions of Eclipse and found nothing interesting. Moreover I copied cvs/team plug-ins between versions and the mentioned difference in behavior remained. I think that the change is somewhere in WID code, however to be 100% sure I have to download both (so far I have only 6.1) and investigate. I will not have time to do this this week, however I'll arrange some time to continue next week.
Can you please explain how the logical model (resource mapping) infrastructure could cause this issue? We likely did make changes in this area. I can look into this possibility if you tell me how the logical model mappings are involved in the branch operation. From my perspective, I would assume that the only thing we would need to do is map the module and library "logical" artifacts to the backing IProject.
Just an update. I managed to install both versions and reproduce the issue.
Logical model (resource mapping) infrastructure was introduced during 3.2. I assume that WID switched to it in WID 6.1.
(In reply to comment #3) > From my perspective, I would assume that the > only thing we would need to do is map the module and library "logical" > artifacts to the backing IProject. It makes sense. Both "logical" artifacts should be mapped to those resources that should be affected during team operations. I think that looking at org.eclipse.team.internal.ccvs.core.mapping.ChangeSetModelProvider could help you a bit. You are probably familiar with the Sync View and the way how it works with change sets. In the change set model, "logical" change sets are mapped to backing projects/resources and when you do branch or another team operation, all the backing resources are affected. Hope it helps.
I see the same behaviour with regular Java projects. After going through the steps and looking at the screen shots again, I am starting to think this is user error. In the older version, it looks like both projects were branched. In the newer version, only one was branched. Hence, the branch tags are not available on the unbranched project. Am I making sense?
I tried the scenario with WID 6.0.2, and it appears that the CVS client behaviour is simply different. The very first time I returned this defect, I said: "I read through all the steps and looked at the screen caps (very well doc'd, thanks). From what I can tell, WID is not involved in the issue at all. For example, do you see the same behaviour with pure Java projects? I think you will. Something must have changed in the CVS client that is part of Eclipse. Please open a bugzilla defect for this problem." I think my initial statement is correct. I tried both WID and Java scenarios, and they are both the same. In WID 6.0.2, I see what the customer sees: "skeleton" projects/folders are created in the branch for all projects. I tried branching pure Java projects from the Java perspective, and the skeletons were created the same as the WID-only scenario. I do not see how WID is responsible for this change in behaviour. There have been some thoughts about the resource mapping support being the cause of the issue. However, WID didn't have this support in WID 6.0.2... and from what I understand, it's the WID 6.0.2 behaviour that is wrong. I don't think the skeleton branch structures should be there. WID 6.1 behaves as expected: a project only shows up in branch if it's part of the branch. Please let me know if anybody disagrees with the above. Question: in a pure Eclipse environment, is the same Java project behaviour seen? Thanks, Grant.
Szymon and myself worked today to figure out this defect. Here's the summary: - the problem only occurs if subfolders are used in CVS - the problem is actually in Eclipse 3.0/WID 6.0.2 (it can be reproduced with simple projects using only Eclipse), wherein skeleton projects were created for projects that weren't in the branch - the bugzillas should likely be closed since the behaviour the user expected is wrong and is fixed in Eclipse 3.2 (WID 6.1) - the original defect is covered by this defect: https://bugs.eclipse.org/bugs/show_bug.cgi?id=47506
Created attachment 145656 [details] Fix v01
Fix v01 released to HEAD. Below you can find how to handle the issue described in the initial comment, when the fix is applied. The issue is: There are two projects LE_Module1 and Module1. They are placed under one common module in cvs. So there are commonModule/LE_Module1 and commonModule/Module1 in the cvs. The LE_Module1 project is branched with BRANCH1. In the cvs repo view when "Tag with Existing"" is used, you can see BRANCH1 for commonModule/LE_Module1 and can't see it for commonModule/Module1. The solution (with the fix applied): In the cvs repo view, you have to select both modules, use "Configure Branches and Versions" and add desired tags (BRANCH1) to both selected projects. Since BRANCH1 is already set for one of modules, you will have to delete it first at "Remembered tags for these projects". Now the tags (BRANCH1 too) will be shown in "Tag with Existing" for either of the projects.
Fix v01 released to 3.5.x too.
Verified in M20090826-1100.
