Community
Participate
Working Groups
I took a file from the head version 1.2 and checked it into a branch where that file didn't exist. Cvs marked version 1.2 on the head as the branch point of this file but didn't put the branch tag into the files set of tags for that version. When viewing the resource history of this file eclipse cvs reports the branch tag as being part of version 1.2 which is not the case. Version 1.2 didn't and does not exist in the branch. If I look at the resource history in the web client for cvs it reports correctly that the branch tag is not on version 1.2 but that 1.2 is the branch point.
What do you mean by "I took a file from the head version 1.2 and checked it into a branch". Could you state the steps in terms of the operations you performed in Eclipse so I can try to reproduce. Thanks.
I noticed this behavior as a result of Bug 54415 but here are the steps. I have two projects - the head and a branch. /x/y/z/fileone.xml v1.2 [head] /x/y [no dir z or fileone.xml in branch] I wanted to port a directory with a set of files from the head to the branch. This directory and set of files did not exist in the branch. I selected the folder from the resource navigator in the head and ctrl-c went to the spot - same path as in the head - in the branch in the resource navigator and ctrl-v. This resulted in the files coming over but the files are still part of the head. Right clicked the added folder in the branch and select cvs then disconnect. I then committed them to the branch. Now I have /x/y/z/fileone.xml v1.2 [head] /x/y/z/fileone.xml v1.2.2.1 [fileone.xml now in branch] Now when I clicked on fileone.xml in the branch and view history it listed: revision tags *1.2.2.1 1.2 branch-tag, other tag, other tag2, other tag3 Now if I look at this same file in the web cvs client i see 1.2.2.1 1.2 other tag, other tag2, other tag3 Branch-Point: branch-tag Hopefully that is enough details. Let me know if you need more.
Yes, I see. In CVS branch tags are associated with the root of a branch. When we show branch tags in the revision history, we show the tags but don't offer any additional explaination. It appears that the web client makes this a bit clearer by indicating that for branches the tag is associated with the root of the branch and not the tail (or whatever it should be called;-). Unless I am missing something, this is a cosmetic issue. I was thrown because the severity was major so I thought that funtionality was broken.
Sorry I should have choose normal. I suppose it is cosmetic but still quite important to have it properly display the files set of tags. It should not show the branch-point as a tag. When it does, it tells the person looking at that file, that that version is in the branch whereas it is not. When a branch is taken from a cvs repository files are initially tagged with the branch label. So if you have a set of files in the head they are all tagged "branch". Now if you add a file to the head after this branch it is not labeled as "branch" thus it is not in the branch. Now if you take that file and backport it to the branch, the version in the head will be marked as a branch point. That doesn't mean that version of the file is in the branch but in eclipse it will appear that it is. Instead what is in the branch is the revision of the file after this branch point. With the current layout of the cvs revision history in eclipse I would say you shouldn't display branch-point tags because they aren't tags they are branch-points.
So currently it is impossible to tell the difference b/t a file with a branch tag and a file that has a branch point of that branch.
I agree that it is worthwhile to make this distinction. The best way is to probably have two clearly labelled panes: one for version tags and one for branch points.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
