Hi,

Le 29 nov. 2015 à 20:00, Dimitris Chloupis a écrit :

> 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.

could be. But we do not want to plug everything. Just having the door opened 
for the next cool VCS.
Even if is only used for git it is good to have a Pharo API that is not the GIT 
API. We do not want git calls mixed everywhere. We want a clean and clear API 
for versioning.
This API also prevents you from git API changes. You will only have one place 
to update and so on.

> Right now Git is by very far the undisputed king of version control and has 
> completely dethroned SVN. 

King because widely used but other are also as valuable if not more.

> 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. 

I do not agree on this point. There is no VCS interoperability layer in Pharo. 
Tools are directly manipulating 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. 

again, I  cannot agree. It is a bad idea to have calls to an external tool / 
library wide spread in the image. We need our own API. It is particularly true 
for git that has an API mixing daily tasks with other power admin commands 
(rewrite of the history with possible code loss).
I do not think we need full support of git in the image, i.e. supporting all 
commands and options, but only what is needed to do correct versioning from 
Pharo (special git commands can still be done with command-line).

> 
> 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
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to