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 <euanmee@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.alios@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 <stepharo@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
>>>
>>>
>>