just for the usual note, thats my personal opinion and in no way try to discourage people just offer a different perspective to this. I always welcome any effort to improve pharo in any way, even for ways I dont care about so much. So keep up the amazing work you guys are doing with Pharo.
On Mon, Nov 30, 2015 at 7:34 PM Dimitris Chloupis <kilon.al...@gmail.com> wrote: > let me give you the thinking of someone that comes from another language > > "What is this ? Ah Pharo > What features it has ? Ah thats some nice cool features, live coding looks > sweet > How about version control ? Hmm no its too weak and their website for > hosting repos is problematic in many cases > Maybe I could use git which I am familiar with ? Ah yes.... but wait there > are many limitations > How about big repos that git excels at ? Nope it crashes Pharo VM. > > Hmm.. ok Pharo looks like nice toy .... will go back to my language of > choice and use it from time to time for foolish experiments. Notice one > thing here, the user never cares about the flexibility of the API. Bottom > line its not about git, or mecurial, or svn. Its about giving something > that the user can use and right now when it comes to version control Pharo > is light years behind. > > Things get popular not because they have nicely designed APIs, they become > popular and rightly so and wisely so because they work. Simple as that. > > I hope at last version control is addressed seriously because its a real > pity Pharo not to be able to use git when there are toy languages like > brainfuck that interface better with it or other version control system. > > I am not against the idea of an abstraction API for Version Control , > great idea do that, but first let get things working properly so we dont > get people scratching their heads on git merges or people struggling to > find out why sthub is down once again. > > On Mon, Nov 30, 2015 at 7:07 PM EuanM <euan...@gmail.com> wrote: > >> We want a system of small objects with loose-coupling, and simple webs >> of message-sends. This allows us power, flexibility, maintainability >> *and* the opportunity to accommodate new requirements. >> >> We always need to bear this in mind. Build for the inevitable changes >> of environment and changes of requirement. You Ain't Gonna Need it >> (YAGNI) is often true, but well-factored code is *always* good. >> >> On 30 November 2015 at 17:02, EuanM <euan...@gmail.com> wrote: >> > Well, personally, I far prefer Mercurial. Which also dethroned SVN. >> > >> > Mercurial has all the power of Git, while providing a more usable API. >> > My mind works like a Smalltalker's, not like Linus's. >> > >> > It's true, some of the more abstruse functions of git require a longer >> > chain of user actions in Mercurial in order to achieve the same end. >> > But typically, the more common functions are more memorable in >> > Mercurial than in git, and my typical use-cases for a DSCM system are >> > less involved than that of the Linux core. >> > >> > On 29 November 2015 at 19:00, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >> And there lies the trap. >> >> >> >> If you end up making something that works with everything, you will >> create >> >> something that just works with everything instead of something that >> works >> >> very well with one thing. Right now Git is by very far the undisputed >> king >> >> of version control and has completely dethroned SVN. >> >> >> >> Ironically the things that make git integration in pharo so hard is >> all the >> >> thing that are there to decouple it from git , like filetree metadata >> , or >> >> continuous support for mcz and monticello. >> >> >> >> In the end you cant have your cake and eat it too. We will have to >> choose >> >> between very good integration with git or average / mediocre >> integration >> >> with multiple backends. >> >> >> >> On Sun, Nov 29, 2015 at 8:15 PM stepharo <steph...@free.fr> wrote: >> >>> >> >>> What I would like for Pharo is to avoid to be bound to a given >> back-end >> >>> for its versionning. >> >>> This master is a step in the right direction >> >>> >> >>> >> >>> >> http://www.hpi.uni-potsdam.de/fileadmin/hpi/source/Technische_Berichte/HPI_54.pdf >> >>> >> >>> Stef >> >>> >> >>> >> >> >> >>
