Anonymous | Login | 04-12-2021 13:19 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0005831 | [Squeak] Tools | major | N/A | 01-25-07 06:16 | 11-18-08 19:56 | ||||
Reporter | wiz | View Status | public | ||||||
Assigned To | |||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.10 | ||||||
Summary | 0005831: [RFE] Changesorters need to report packages of methods and Classes | ||||||||
Description |
This is report item for the needed tool Ralph Johnson mentioned in: http://lists.squeakfoundation.org/pipermail/v3dot10/2007-January/000134.html [^] |
||||||||
Additional Information |
This is part of the Changesets and Monticello must interoperate repair. ChangeSorters need to allow coders easy access and visiblity to know which MC packages the changesets are affecting. So coders can see and choose to limit a change set to just one package. Or not (as the need arises) What can be tracked can be changed and controled. Right now the catagories and packages that methods belong to are opaque to change sets because change sets predated MC and its reliance on method and system catagories for packaging. |
||||||||
Attached Files |
![]() ![]() ![]() |
||||||||
|
![]() |
|||||||||||||||||||||
SYSTEM WARNING: Creating default object from empty value SYSTEM WARNING: Creating default object from empty value
|
![]() |
|
(0009196 - 1123 - 1225 - 1225 - 1225 - 1225 - 1225) wiz 01-25-07 06:35 |
analysis I started looking into this and found change sets sorters and organizers to be much more numerous and intricate that one would at first expect. Pavel seems to have looked at this too and did some major refactoring of the change sorter work. Not knowing what he had done I have probably done similar work moving annotation catagory selectors to SystemsNavigation and starting to generalize the annotations. Part of the work in the latter was to add simple annotations for selector, class, and package. It seems to me the first iteration of the change set stuff is just to add the package name on to the messageselector in the selector list pane. And the class catagory in the class pane. The user will have to map that to the MC package (If there is one). It will be much more work to go beyond that . (For one sorters will have to learn how to talk to mc. ) This is a massive amount of learning for me. I am coming to this ignorant of both change sorting and MC organization. However this is here on mantis in hopes the experts who know will chime in. Yours in service, --Jerome Peace |
(0009198 - 629 - 663 - 663 - 663 - 663 - 663) RalphJohnson 01-25-07 15:44 |
I think you are making this much harder than it should be. There are many change sorters, but there is only one ChangeSet. All I want is for ChangeSets to be able to tell me what packages they influence. Start by adding a single "packagesInfluenced" message that returns a list of package names. Then you could add a field in one of the change sorters that displays this information. We might then add the command to save all the packges that have been influenced (which would require a connection to MC) but it would be useful even if we didn't get that far. I'd be happy with the just the method on ChangeSet. -Ralph |
(0009201 - 1740 - 1884 - 1884 - 1884 - 1884 - 1884) wiz 01-26-07 02:33 |
Hi Ralph, Thanks for the suggestion. I'll look into it. I am happy if it turns out not to be hard. When the confusion settles down it usually is stunningly simple. I'm just at the beginning of learning about classes I've only used from the outside. Actually I know little about ChangeSets and not too much about ChangeSorters. From where I am starting (think first tarot card, fool about to step off cliff) it looks like the closure set of methods and classes I need to understand to make wise choices is quite large. What I have been doing is a reasonable first step. I had previously moved CodeHolder annotation methods into System Navaigation and made one method which takes a list and returns a string of annotations from the list. Then I added a #package annotation which returns either the method catagory or class catagory. That's the clue to the package. From the clue it is then necessary to determine which package the method belongs to or would belong to if there was a package for it. After that there is ambiguity in the package naming system. So you have to consult what MC thinks is the Package. Plus there will be cases with new stuff where MC will not have an opinion since the potential package has not been saved. I am not a MC user. I repair morphic and it is necessary AFAIK to do that with changesets. What I know from using change sorters to file out code it that seeing the catagories (method and class) would give a heads up about package confilcts. So I headed for that first. The beauty of Mantis is that someone who knows the particular solution to the problem you suggested might chime in. Thanks again for your encouragement and support. Yours in service, --Jerome Peace |
(0009214 - 875 - 899 - 1063 - 1063 - 1063 - 1063) RalphJohnson 01-26-07 13:41 |
You don't actually need to check with MC to find out which package some code is in, though you do need to check with MC to know where that package is located. MC uses the PackageInfo scheme for packages. This is hack that mostly works, see http://www.wiresong.ca/Monticello/UserManual/PackageInfo/ [^] for details. Look at the PackageInfo class. In 3.9, every method in the standard image is in a MC package somewhere. This will continue to be trur in 3.10. The rules of PackageInfo will tell you which package a method is in, MC will tell you which server has the source for the package. The Morphic code is all in MC. You can actaully fix Morphic using MC, though change sets are probably easier for you because a single fix usually involves several packages, so if you used MC you'd have to release a set of interlocking package versions instead of one change set. |
(0009294 - 1097 - 1163 - 1163 - 1163 - 1163 - 1163) wiz 01-30-07 20:46 |
Hi Ralph I've spun off ChangeSet>>#packagesInfluenced into its own focused report. I've gained some insights in looking into it. And believe it to be a more difficult thing to achieve properly than what I had originally set out to do with this report. I am going back to focusing my efforts on the Changesorter reporting problem. That means I only have to report current catagories of the listed classes and methods. It will be useful to have that information available when looking at the changesorter. It does not encompass reporting the packagesInfluenced by a class reorganize change (which is where the biggest mischief occurs). Also by focusing on this it will give me a chance to do some other work that needs to be done. And also a chance to get more insights into code I have not worked with before. It might be good to put out a call or to persuade those responsible for packages to look into the other enhancement. They will have at least half of what needs to be known under their belt. They may also learn something they need to know. Yours in service, --Jerome Peace |
(0009420 - 1809 - 1959 - 1959 - 1959 - 1959 - 1959) wiz 02-03-07 22:56 |
Uploaded: OldChangeSorter-wiz.1.cs ( a Copy of the Squeak-7067 ChangeSorter). This is not part of the fix but provides a way have the two changesorters in the image at the same time. I wanted it for testing the behaviors side by side. and ChangeSorterNotes-wiz.2.cs ( the patch to Squeak-7067 ChangeSorter) This adds an annotation to the class and method lists. Here the annotation is the Class catagory for the class. And either the *extention method catagory for the methods or if it has a normal catagory then the catagory for the class is provided. From the annotations you have a clue as to which packages are affected. It is very useful as an awareness tool. Limitations:(!!!) Only the current catagory is shown. If you have changed packages by moving methods among catagories you don't get to see the historical catagory. (Though I think bert did something to the version histories that helps with this.) Also if you have played with catagories in any way then the cs will output a Class reorganize at the end of the cs. This tool does not help alot in determining if that will muck up anything when it is read back in. (Hint: Given enough time the reorganize will surely mess up the classes most subject to change) A note on design choices. Inorder to keep the patch changes all in one class (and package) the annotation stuff has been added into the change sorter class. Originally I had been moving the annotation stuff out of CodeHolder and into SystemNavagation. If I kept it that way then the patch would span two packages rather than one. Furthermore since the current packages do not have the sysnav additions yet those would have to be updated before code depending on them could be used. So this is a necessary transitional choice for simplicity sake. |
(0010713 - 591 - 669 - 669 - 669 - 669 - 669) edgardec 05-13-07 08:38 |
Jerome: Here I put how you could know what packages touch any change set Do ReleaseBuilderFor3dot10 new packagesInfluenced , you could select a .cs into your disk, the method return what packages this .cs could change without loading nothing in your image. Another way is , if you load some as in the current update process ReleaseBuilderFor3dot10 new packagesList packagesList is called in the update building process, but you could reuse to will. If still you think what I should put your code or could improve all, I happy put in 3.10. Like know what Ralph have to said |
(0010714 - 591 - 669 - 669 - 669 - 669 - 669) edgardec 05-13-07 08:39 |
Reminder sent to: RalphJohnson Jerome: Here I put how you could know what packages touch any change set Do ReleaseBuilderFor3dot10 new packagesInfluenced , you could select a .cs into your disk, the method return what packages this .cs could change without loading nothing in your image. Another way is , if you load some as in the current update process ReleaseBuilderFor3dot10 new packagesList packagesList is called in the update building process, but you could reuse to will. If still you think what I should put your code or could improve all, I happy put in 3.10. Like know what Ralph have to said |
(0010715 - 591 - 669 - 669 - 669 - 669 - 669) edgardec 05-13-07 08:40 |
Reminder sent to: wiz Jerome: Here I put how you could know what packages touch any change set Do ReleaseBuilderFor3dot10 new packagesInfluenced , you could select a .cs into your disk, the method return what packages this .cs could change without loading nothing in your image. Another way is , if you load some as in the current update process ReleaseBuilderFor3dot10 new packagesList packagesList is called in the update building process, but you could reuse to will. If still you think what I should put your code or could improve all, I happy put in 3.10. Like know what Ralph have to said |
(0010718 - 486 - 582 - 582 - 671 - 671 - 671) wiz 05-13-07 19:04 edited on: 05-13-07 19:08 |
Hi Edgar, I just noticed Pavels note to the list about ChangeOrganizer 0004825. As I look at the report I realized that while ithe two changes might not conflict, they probably do. I was not aware of his stuff when I created my enhancements. Pavel's changes seem very extensive. So my suggestion is put pavel's changes in. Then let me try my stuff here on top of that and see what is needed to get this to work. Sigh. Yours in curiosity and service, --Jerome Peace |
(0010719 - 352 - 412 - 412 - 501 - 501 - 501) wiz 05-14-07 00:52 |
Ha. This cs works even after ChangeSorter310.st (from manits 0004825) is installed. What I did. From a fresh 7097 I updated from server to 7108. Installed ChangeSorter310.st Then installed ChangeSorterNotes-wiz.2.cs And I had no problems. I could get a changesorter and see the class-catagory/package annotations for each class and method. |
(0010721 - 83 - 89 - 89 - 89 - 89 - 89) edgardec 05-14-07 08:48 |
This now is 7110ChangeSorterNotes-wiz.cs and was in updates for 3.10 Thanks Jerome |
(0010916 - 495 - 607 - 607 - 607 - 607 - 607) wiz 07-23-07 02:53 |
from [V3dot10] Some notes on 7130 Andreas Raab andreas.raab at gmx.de Sun Jul 22 22:17:37 UTC 2007 * 7110ChangeSorterNotes-wiz.cs This broke the ability to move changes between two change sets in a dual change sorter. To wit: In a dual change sorter, select any single method and choose to "move method to other side". Boom. Uploaded ChangeSorter-m...thodToOther.st which patches the move routine. Copy to other side had worked but I missed this one. Thanks Andreas. |
(0010922 - 134 - 158 - 158 - 158 - 158 - 158) wiz 07-23-07 20:29 |
Reminder sent to: edgardec Hi Edgar, I fixed the problem Andreas reported. So there is another patch to add to your growing work load. Cheers amigo, -Jer |
(0010929 - 90 - 96 - 96 - 96 - 96 - 96) edgardec 07-24-07 11:36 |
This now is 7132ChangeSorter-methodToOther.cs and was in updates for 3.10 Thanks Jerome ! |
(0012778 - 66 - 66 - 66 - 66 - 66 - 66) KenCausey 11-18-08 19:56 |
This was harvested in update 7110 and 7132 and released with 3.10. |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
144 total queries executed. 70 unique queries executed. |