Thanks Mariano. Lukas, I just remembered why I chose to 'break' the OB versions button. The collecting of method versions happens in OBMethodNode>>versions. When a node is selected in a method list, that node is sent the message #versions. It's nearly impossible (as far as I can tell) to not touch anything because I would have to replace the model class of the method nodes (OBMethodNode) with a custom class. There are many references to OBMethodNode all over the place that would probably break unless I replaced them too. So, as I see it my 'ugly' approach is really a compromise to not spending 20 hours replacing OBMethodNode. Or did you have another idea? I'm not an OB guru... Cheers, Max On 19.03.2011, at 19:38, Mariano Martinez Peck wrote:
On Sat, Mar 19, 2011 at 3:10 PM, Max Leske <maxleske@gmail.com> wrote: I don't have an account for the book. Who should I turn to for this?
Me or any other of the admis. I have just created one for you and sent by private the data.
Thanks
Mariano
Max
On 19.03.2011, at 14:32, Mariano Martinez Peck wrote:
can you add your project in
http://book.pharo-project.org/book/PharoTools/
?
On Tue, Mar 15, 2011 at 7:02 PM, Lukas Renggli <renggli@gmail.com> wrote:
I'll defenitely try to come up with something to access github soon. It will probably not use OB though because that's just too much of a hack. Especially because it effectively disables the version browser for changes files.
You really don't need to hack OB: Why don't you just add a completely new command (the complete refactoring infrastructure was added that way and can be optionally loaded and unloaded) and let the Git history live aside of the traditional versioning functionality?
Lukas
-- Lukas Renggli www.lukas-renggli.ch