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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]> 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
> >>>
> >>>
> >>
>
>

Reply via email to