Summary: | Branch creation problem in CVS | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Brian Young <Brian_Young> | ||||
Component: | Team | Assignee: | Szymon Brandys <Szymon.Brandys> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | edwinc, gdtaylor, john.arthorne, Mike_Wilson, Szymon.Brandys | ||||
Version: | 3.2.2 | Keywords: | investigate | ||||
Target Milestone: | 3.5.1 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Brian Young
2009-02-04 16:44:21 EST
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. |