I hear the new filesystem might do just that. I dont know I am new to all this. 

But I dont believe integrating github with squeak or pharo is that hard anyway. 

I am already working with file outs , tedious but not that hard. And if I cannot find an existing solution
that makes me happy , I am more than willing to implement my own library for integrating github inside pharo. 

Hopefully it will work for squeak too. 


I was working with emacs for python and magit was great. 

Where there is a will there is a way, 



________________________________
 From: Frank Shearar <frank.shearar at gmail.com>
To: dimitris chloupis <thekilon at yahoo.co.uk>; The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org> 
Sent: Friday, 21 December 2012, 0:16
Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
 
Just a note: github does not replace SM. It does not replace rubygems.
It's a fantastic tool for versioning source control.

I have a toolbox. It has a hammer AND a screwdriver.

frank

On 20 December 2012 22:15, dimitris chloupis <thekilon at yahoo.co.uk> wrote:
> SqueakMap is dead, SqueakSource dead, later SmalltalkHub will be dead.
>
> I am coming from pharo by the way, I am new with smalltalk, I was a python
> developer.
> And I love squeak too.
>
> I dont understand why every smalltalk problem should be solved by smalltalk.
>
> Github is a great community , already has gathered tons of ruby and python
> projects, js and many more.
>
> I think its a great candidate for smalltalk, no offense intended but
> definitely better that what SmalltalkHub can offer.
>
> I want to embrace at times all these smalltalk technologies, but is hard to
> abandon Gihub that I have used for my projects and support the smalltalk
> solutions instead.
>
> I dont want to downgrade the hard work of good people, but its hard to
> compete with products that are designed full time by big teams and matured
> through thousands of use cases.
>
> My vote goes to Github.
>
> ________________________________
> From: Göran Krampe <goran at krampe.se>
> To: The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Thursday, 20 December 2012, 23:14
> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>
> Hi folks!
>
> As the author of SqueakMap, long time Squeaker (and nowadays both Squeaker
> and Pharooner) and also involved in some other related projects
> (SmalltalkHub and more) my view might be of some interest.
>
> First of all, Angel compares with the rest of the world - but we have both
> historic and technical differences at play. Some things worth noting:
>
> - SqueakMap was indeed started out as a generic package *catalog*. It is not
> a SCM tool. It was format agnostic from the very beginning.
>
> - Monticello and SqueakSource came from Avi. Superb tools but when
> Squeaksource came I quickly warned the community that it would deminish
> SqueakMap because it overlapped and "took over" several "catalog" aspects. I
> was right unfortunately, but at the same time SS was great and has served us
> very well in its own right.
>
> - Noone has really taken SM and moved it forward. I also don't have that
> amount of free time anymore.
>
> - SqueakMap is dead. Face it. :) It is not the future IMHO.
>
> - Monticello and Metacello are the de facto standard these days for SCM and
> package loading. Metacello took the whole dependencies/tagging/releases
> issue and simply rode on MC to solve it. I have felt it looks overly complex
> but it's mostly some line noise - it is not that complicated.
>
> - This also means that for a very, very long time package management and
> source code management will be forever "intertwined" in the Smalltalk world.
> Personally I say - fine! Again, let's just embrace it and go.
>
> - The advantage is that Metacello "configurations" is "just code" and can
> offer functionality totally independent of the hosting platform for MC. So
> it doesn't matter if you load a Metacello configuration from a website, from
> SS or SS3 or Smalltalkhub - it all works the same!
>
> - Monticello AND Metacello are meant to work in Squeak too. I haven't tried,
> but I presume Metacello works or is very close to working?
>
> - Pharo is betting hard on Smalltalkhub. It is a really nice system AND
> there is also an image side client tool brewing for it! This means the
> equivalence of the SqueakMap Package Loader will be easy to build in Squeak
> for Smalltalkhub.
>
>
> So my advice would be:
>
> 1. Keep SqueakMap on oxygen for a little while longer while we get ready to
> ditch it. Really.
>
> 2. Bet hard on Monticello (we already do, right?) and Metacello for Squeak.
> Make sure they work. Embrace Metacello even if it does look a bit complex to
> begin with. There are lots of articles, tutorials and tons of examples to
> just copy from. I have written two configurations these last two days and
> "the shit works". Good work Dale! :)
>
> 3. Get involved in Smalltalkhub and help out making it work fine for Squeak,
> note the name - *Smalltalk* hub. It's not Pharohub! Don't set up your own
> unless for some odd reason Pharo makes it uninhabitable for Squeak and turns
> it into "Pharohub".
>
> Note that Smalltalkhub is "just" a new SS, but much more solid architecture,
> really snazzy modern web UI, offering githubish features and bloody hell, I
> mean, it can show diffs right there in the browser!
>
> Smalltalkhub also has a really cool architecture so the coding fun is rated
> A++, Nicolas is busy as a bee making it better, better. I think it should be
> seen as a unifying playground and Metacello as the "glue" that makes it
> possible to have projects tailored for both Squeak and Pharo. It has many
> functions for EXACTLY that.
>
> Either way, I am putting my efforts right there. IMHO the Squeak community
> should do so too. If the Squeak community can ride a bit on the momentum in
> Pharo - there is really no reason not to.
>
> regards, Göran
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121220/2ec50b01/attachment.htm