On 11 March 2013 22:06, Frank Shearar <[email protected]> wrote: > On 11 March 2013 19:00, Igor Stasenko <[email protected]> wrote: >> On 11 March 2013 19:06, Frank Shearar <[email protected]> wrote: >>> On 11 March 2013 17:54, Igor Stasenko <[email protected]> wrote: >>>> pff... really people... i am thinking how to streamline our existing >>>> development process.. >>>> and instead i hear once again about git. >>> >>> Camillo needs to hit you around the head with a command line. You >>> haven't used it. You've heard several people who have used both >>> Monticello and git extensively say that git beats the crap out of >>> Monticello. Go and learn git properly. THEN come back and maybe we can >>> have a conversation. >>> >> I always using git from command line. And let me remind you it was me who >> created Cog mirrors on gitorious.. so, you shoot into the sky here. >> But i want more than that.. and why i happy to see that github proposes more >> on top, i do not really see how you can integrate that with usual >> workflow of smalltalk developer >> (means navigating/debugging living code in image). > > OK, fair enough. I had indeed forgotten about your gitorious work, and > in fact if I recall correctly you tried to pushed the VM folk into > moving from subversion to git. My apologies. > >>>> okay, lets throw away MC & stuff, migrate everything on file-based >>>> file-per-method git repository >>>> and then navigate diffs on github, and trying to find senders or >>>> implementors of selector using web browser . >>> >>> I do believe you ought to take a moment and go read the archives. >>> Also, I happen to nearly violently disagree with the file-per-method >>> approach, but that's an entirely different kettle of fish. >>> >>> But you know what, just forget it. It's not your problem, other people >>> are already solving the problem, and one day hopefully you'll forget >>> all about this while quietly your tools happily use git under the >>> hood, where you neither know nor care. >>> >> I actually don't care where files stored , in what format and what >> service it using. >> I want to make my life easier integrating those services with image, >> so i could, without switching >> contexts (like between image/web browser), do my work faster and more >> efficient. > > Yes, agreed. > > So if I can summarise, > > * git is not an answer for you because you don't care about the format > source is stored in. > * git is an answer for me because it immediately gives you a fantastic > user interface and hooks into just about everything. > * github is not an answer for you because it doesn't provide you with > any tools more advanced than a diff > * github is an answer for me because you can always implement your own > hooks for triggering CI, arbitrary code analysis, etc. Github's commit > API will let you give the green light or red light to any commit so > you can see at a glance how good a pull request is. >
So, lets get back to the topic. Right now we have more or less same with MC + jenkins.. yes.. it may be ugly and inferior etc.. but if we compare human resources.. But see, the model right now is that to review the code, i must go to bug tracker/git (or if it is commit in some other project, go to that project repo) and manually load code from there.. and then after i loaded it into image, fun begins.. except that after review i have few choices: - send mail to author that his work sucks - say, code is fine and go back to web page, click here and there and mark it as OK.. now what i want is a tool which could help me to put a comments as i looking at code and then when i done, package that and upload where i want.. then other guy can load it into image and see my remarks.. yes, maybe it is too complicated/idealistic .. propose yours. > But of course there's nothing stopping one using github OR an-image > tools. (Or tools that produce custom images based on github commits > that run analyses and then persist somewhere so you can (a) see the > analyses immediately and (b) play around with the code. > > Mainly I think it's a mistake to reinvent tech _just because_ you > simply must work in an image. That's the core behind my moaning. (And > yes, I am working on addressing these issues, so I'm not _just_ > moaning.) > Yes, please.. but i hope you agree with me, that reviewing smalltalk code on web page or in text/diff viewer is not something you can do, if you wanna do it for real, not just looking for typos :) For doing it for real, you need an image. > frank > -- Best regards, Igor Stasenko.
