On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:

Hi,

I continue the discussion here because I really would like to know the cons of using Git + Pharo.

From kilon's video (thx) and the discussion that followed, I have the following questions about possible drawbacks of Git+Pharo:��

- The most important point to me is: does ConfigurationOf work correctly with a repo on GitHub for example? any example somewhere?��

When using git, you do not need to use a ConfigurationOf as all of the packages are versioned together so it isn't necessary ��to track individual mcz package versions ... you only really need a baseline to specify package/project dependencies.��

Instead of a ConfigurationOf you use a BaselineOf which has a single baseline: method[1]. The baseline: method is like any other baseline, except it isn't necessary to explicitly specify a repo - the repo used for the packages is the same one as the BaselineOf was loaded from.

To load a baseline from a github repo you use an expression like the following:

�� Metacello new

�� �� baseline: 'Cryptography';

�� �� repository: 'github://GsDevKit/Cryptography:master/repository';

�� �� load: #('Cryptography')

The :master in the repo specification can the name of a branch (master branch in this case), a SHA, a tag, or a tag pattern (1.1.? will load tags 1.1.0, 1.1.1, 1.1.2, etc.).

To load from a local git clone (filetree repo) you use something like the following:

�� Metacello new

�� �� baseline: 'Cryptography';

�� �� repository: 'filetree:///opt/git/Cryptography/repository';

�� �� load: #('Cryptography')

[1]��https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfCryptography.package/BaselineOfCryptography.class/instance/baseline..st

- we should go to command line to commit/update but that could be saved with what has been done by Dale in tODE (shell integration, UI to commit, push/pull) IIUC. right?

In tODE I've wrapped a large chunk of the shell command line git api with Smalltalk ... tODE has it's own command line, so git commands can be run from within tODE on the command line. Other tools make calls to he Smalltalk api.

��

- Merging could be harder because it would rely on git tools?

When merging with git, you may be merging multiple packages plus doc files, etc., at once, so the tool required for merge must be built to work with git merge meta data ... there are external merge tools, but I built a merge tool in tODE that I actually prefer over the other available merge tools ...

- opening a filetree repo in MC does not show the latest content since it is the local git repo that may not be in sync with the remote one => you should first pull the repo

This is actually an advantage ... when you have a local git clone, you control when and how projects are updated ... how many times have previously working build procedures suddenly stop working because someone has made a change to a ��configuration of a project? With local clones your environment is static and stable until you are ready to upgrade to a new version and then you do so in a controlled manner.

��If you use a spec like 'github://GsDevKit/Cryptography:master/repository', you are really using the latest version of master branch (bleeding edge for a remote repo)...In theory you can "require" that all tests pass before a change is merged into the master branch (using pull requests and travis-ci). so using the latest master branch should always be "safe".

Dale