Community
Participate
Working Groups
Created attachment 104900 [details] Missing functionality createDummyInvalidLiteralExp does not invoke initASTMapping thereby preventing the InvalidLiteralExp being traced back to its origin by an editor problem marker. [The call sites can be modified instead if API compatibility is critical.]
Committed the patch with a change to add a private overload of createDummyInvalidLiteralExp for compatibility. The merge with HEAD for the 1.3 release will increase the visibility to protected.
Fix available in R1_2_maintenance: 1.2.1.M200807161339.
Something funny is happening with CVS tags. The fix is not available in 1.12 which is tagged 1.2.Maintenance. The fix is available in 1.12.2.2. Surely 1.x is the next release and branches are maintenance?
(In reply to comment #3) > Something funny is happening with CVS tags. No, it all looks like normal CVSisms to me. > The fix is not available in 1.12 which is tagged 1.2.Maintenance. The R1_2_maintenance tag is the starting tag of the 1.2.x maintenance branch, not its terminus. Version 1.12 is not supposed to have the fix because the fix was committed later, on the maintenance branch. > The fix is available in 1.12.2.2. > > Surely 1.x is the next release and branches are maintenance? CVS's version numbers have no useful relation to the component/project versioning. The numbers are always 1.something, even for a 2.x or 3.y project. The version of this file is what it is simply because it had never previously been changed on a branch (other than HEAD). This fix will be released in the MDT OCL 1.2.1 release, later this month. At that point, this version of the file (or a later one on the same branch) will be tagged with R1_2_1. Then, the maintenance branch continues towards 1.2.2 and 1.2.3 ...
Yes, I know 1.x is always 1.x. I thought 1.x was HEAD, and 1.x.y.z were branches. I've twice reported failures that seem to be due to an inability to use the development brach. What is it called? [There may also be an Eclipse CVS bug confusing me, after switching to 1.12.2.2 Synchronize refused to show different content!]
(In reply to comment #5) > Yes, I know 1.x is always 1.x. I'm confused by your references to "1.x" It is unfortunate that OCL releases are currently numbered "1.x" as are many of the versions in the CVS repos. Perhaps, we can use "OCL 1.x" and "CVS 1.x" in referring to version numbers to keep them straight. > I thought 1.x was HEAD, and 1.x.y.z were branches. CVS 1.x versions are usually the HEAD branch, and CVS 1.x.y.z versions are always branches. However, a branch will have a CVS 1.x version of a file until some change is made to it on that branch. I have never seen a CVS 2.x version on any file in any CVS repository. > I've twice reported failures that seem to be due to an inability to use the > development brach. What is it called? How are you trying to "use" the development branch? It is named according to the Eclipse convention, R1_2_maintenance. So, in the "Team -> Switch to another branch or version..." menu action, this is the branch name that you enter or select from the list (if you do a "Refresh Tags and Branches").
I've been endeavouring to use only the HEAD and discovering that synchronizing with that does not give me the expected updates. The earlier problem with Bug 241421 is hard to explain. I could not see CVS 1.12. Since CVS 1.12 had existed for a long time, I'm inclined to put this down to user trouble with multiple workspaces. This time it's much clearer, I've done multiple synchronizes. I can see CVS 1.12 and it doesn't have the fix. CVS HEAD synchronisation says I should be using CVS 1.12.
(In reply to comment #7) > I've been endeavouring to use only the HEAD and discovering that synchronizing > with that does not give me the expected updates. If you want to follow the maintenance branch in CVS, you really need to "Switch to" it instead of following HEAD. HEAD won't have maintenance fixes until they are merged from the branch. I expect to do that soon, because EMF has already bumped the Ecore plug-in to version 2.5.0, which will be published in their next I-build. > The earlier problem with Bug 241421 is hard to explain. I could not see CVS > 1.12. Since CVS 1.12 had existed for a long time, I'm inclined to put this down > to user trouble with multiple workspaces. > > This time it's much clearer, I've done multiple synchronizes. I can see CVS > 1.12 and it doesn't have the fix. CVS HEAD synchronisation says I should be > using CVS 1.12. I don't understand why you would expect a fix that was committed to the maintenance branch after the 1.12 version to be in the 1.12 version. It's only in the 1.12.2.2 version. When it is merged to HEAD, then it will also be available in the 1.13 or some later version (depending on the timing of the merge).
OK I understand now. I assumed that all development was for OCL 1.3.0 and selectively retrofitted to OCL 1.2.1. So we are temporarily in the strange position that the maintenance branch is more advanced than the development (HEAD) branch.
Closing after over a year in verified state.
