Hello, I had some spare time and I built a prototype web application for comparing Monticello versions. I developed it using Seaside and Monticello version diff implementation in Pharo. It was super easy to reuse the classes which are responsible for downloading, comparing and generating diffs of Monticello packages. Once again I see how extraordinary it is to have such open system as Pharo. I made this web app for my work with students as often I need to compare their versions of packages across different projects/repositories. For instance, the package is uploaded to PillarHub-Inbox and I want to compare and discuss changes against the main repository. Having this in mind I created a small web app called "Monticello Seaside Review" (didn't get any better). You may find an example review here: http://review.pharocloud.com/msr/review/ehx82xz90kpnm56u9exkrul5q/4 You may also log in to this instance and play with it as it is not really used so no problem if it crash for some reason :) The sources of the project can be found here: http://smalltalkhub.com/#!/~mikefilonov/MonticelloSeasideReview I would be happy of someone finds the project useful and contributes some ideas. Thank you, Mike -- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Excellent We were discussing with alberto and martin about a tool to support code review :) Le 3/2/15 18:41, mikefilonov a écrit :
Hello,
I had some spare time and I built a prototype web application for comparing Monticello versions. I developed it using Seaside and Monticello version diff implementation in Pharo. It was super easy to reuse the classes which are responsible for downloading, comparing and generating diffs of Monticello packages. Once again I see how extraordinary it is to have such open system as Pharo.
I made this web app for my work with students as often I need to compare their versions of packages across different projects/repositories. For instance, the package is uploaded to PillarHub-Inbox and I want to compare and discuss changes against the main repository.
Having this in mind I created a small web app called "Monticello Seaside Review" (didn't get any better).
You may find an example review here:
http://review.pharocloud.com/msr/review/ehx82xz90kpnm56u9exkrul5q/4
You may also log in to this instance and play with it as it is not really used so no problem if it crash for some reason :)
The sources of the project can be found here: http://smalltalkhub.com/#!/~mikefilonov/MonticelloSeasideReview
I would be happy of someone finds the project useful and contributes some ideas.
Thank you, Mike
-- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
What I would love is to bind it with epicea. The users can comment the files. What is cool with Epicea is that a change has semantics and a before and after state. Finally often you do a change (composed of different modifications) and that you do not want to see all the modifications one by one but Ok I split this method into one in the superclass and one in the superclass. Side note: The more I think the more I think that epicea entity commenting entiy should be held in a separate file ( but I should discuss with Martin). Now I was in the process to propose to students to build an in image tools for support the code review. But having a server is much better. Like that people can share comment. Where you tool takes its input? Stef
Hello,
I had some spare time and I built a prototype web application for comparing Monticello versions. I developed it using Seaside and Monticello version diff implementation in Pharo. It was super easy to reuse the classes which are responsible for downloading, comparing and generating diffs of Monticello packages. Once again I see how extraordinary it is to have such open system as Pharo.
I made this web app for my work with students as often I need to compare their versions of packages across different projects/repositories. For instance, the package is uploaded to PillarHub-Inbox and I want to compare and discuss changes against the main repository.
Having this in mind I created a small web app called "Monticello Seaside Review" (didn't get any better).
You may find an example review here:
http://review.pharocloud.com/msr/review/ehx82xz90kpnm56u9exkrul5q/4
You may also log in to this instance and play with it as it is not really used so no problem if it crash for some reason :)
The sources of the project can be found here: http://smalltalkhub.com/#!/~mikefilonov/MonticelloSeasideReview
I would be happy of someone finds the project useful and contributes some ideas.
Thank you, Mike
-- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Where you tool takes its input?
The tool requires a full URL to mcz package file for both base and target versions. This allows to compare versions on different locations. I attached the screenshot of the form : <http://forum.world.st/file/n4803522/Monticello_Seaside_Review.png> You may easily log in http://review.pharocloud.com/ as there is no registration and stuff (I used Mozilla Persona) so you see the form like in three clicks.
Ok I split this method into one in the superclass and one in the superclass.
This is one of the reasons why my tool requires full URL for both base and target - so it is not restricted only to ancestor comparing. With Monticello Seaside Review you can compare v43 with v46, which could be the final version of you change.
What I would love is to bind it with epicea. The users can comment the
Sorry, but I did not quite get the idea. Could you please describe a use case how Epicea is used in a development process? Thank you, Mike -- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443p4803522.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Hi Mike, I just tried your application and it works well. Simple but effective. It is of course sometimes a bit hard to get to an actual URL ;-) Good work. Sven
On 04 Feb 2015, at 02:33, mikefilonov <mikefilonov@gmail.com> wrote:
Where you tool takes its input?
The tool requires a full URL to mcz package file for both base and target versions. This allows to compare versions on different locations. I attached the screenshot of the form :
<http://forum.world.st/file/n4803522/Monticello_Seaside_Review.png>
You may easily log in http://review.pharocloud.com/ as there is no registration and stuff (I used Mozilla Persona) so you see the form like in three clicks.
Ok I split this method into one in the superclass and one in the superclass.
This is one of the reasons why my tool requires full URL for both base and target - so it is not restricted only to ancestor comparing. With Monticello Seaside Review you can compare v43 with v46, which could be the final version of you change.
What I would love is to bind it with epicea. The users can comment the
Sorry, but I did not quite get the idea. Could you please describe a use case how Epicea is used in a development process?
Thank you, Mike
-- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443p4803522.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 04 Feb 2015, at 09:33, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Mike,
I just tried your application and it works well. Simple but effective.
One question: Could we benefit from that for daily review of Pharo fixes?
It is of course sometimes a bit hard to get to an actual URL ;-)
Good work.
Sven
On 04 Feb 2015, at 02:33, mikefilonov <mikefilonov@gmail.com> wrote:
Where you tool takes its input?
The tool requires a full URL to mcz package file for both base and target versions. This allows to compare versions on different locations. I attached the screenshot of the form :
<http://forum.world.st/file/n4803522/Monticello_Seaside_Review.png>
You may easily log in http://review.pharocloud.com/ as there is no registration and stuff (I used Mozilla Persona) so you see the form like in three clicks.
Ok I split this method into one in the superclass and one in the superclass.
This is one of the reasons why my tool requires full URL for both base and target - so it is not restricted only to ancestor comparing. With Monticello Seaside Review you can compare v43 with v46, which could be the final version of you change.
What I would love is to bind it with epicea. The users can comment the
Sorry, but I did not quite get the idea. Could you please describe a use case how Epicea is used in a development process?
Thank you, Mike
-- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443p4803522.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
If the app is useful I will go on with the development. I have following roadmap in my mind: * REST API so review can be created automatically * Mail notifications * List of reviewers * Review state like "approved, denied", minimum number of approves need to for review to "pass" * Comment linked to a line -- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443p4803559.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 04 Feb 2015, at 09:46, Marcus Denker <marcus.denker@inria.fr> wrote:
On 04 Feb 2015, at 09:33, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Mike,
I just tried your application and it works well. Simple but effective.
One question: Could we benefit from that for daily review of Pharo fixes?
I don't know if it can compare slices (MCZ's with dependent/required packages).
It is of course sometimes a bit hard to get to an actual URL ;-)
Good work.
Sven
On 04 Feb 2015, at 02:33, mikefilonov <mikefilonov@gmail.com> wrote:
Where you tool takes its input?
The tool requires a full URL to mcz package file for both base and target versions. This allows to compare versions on different locations. I attached the screenshot of the form :
<http://forum.world.st/file/n4803522/Monticello_Seaside_Review.png>
You may easily log in http://review.pharocloud.com/ as there is no registration and stuff (I used Mozilla Persona) so you see the form like in three clicks.
Ok I split this method into one in the superclass and one in the superclass.
This is one of the reasons why my tool requires full URL for both base and target - so it is not restricted only to ancestor comparing. With Monticello Seaside Review you can compare v43 with v46, which could be the final version of you change.
What I would love is to bind it with epicea. The users can comment the
Sorry, but I did not quite get the idea. Could you please describe a use case how Epicea is used in a development process?
Thank you, Mike
-- View this message in context: http://forum.world.st/Monticello-review-web-application-tp4803443p4803522.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (4)
-
Marcus Denker -
mikefilonov -
stepharo -
Sven Van Caekenberghe