I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual. I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects. Are there any insights to this or pointers to an up-to-date documentation? thanks, Norbert
Hi Norbert, I think this article by Yuriy describes pretty fine how to work with Baselines, Configurations and GitHub. http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht... <http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht...> cheers! Esteban ps: In fact, I would like to include it as âofficial documentationâ :P
On 25 Jan 2016, at 18:09, Norbert Hartl <norbert@hartl.name> wrote:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
thanks,
Norbert
Thanks Esteban, in the tutorial there is a mentioning that one can use bitbucket as well. When I try using a bitbucket url for a repository I get an ZnUnknownScheme error. Is there any prerequisite for using different schemes. I loaded newest zinc http without success. thanks, Norbert
Am 25.01.2016 um 18:14 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
Hi Norbert,
I think this article by Yuriy describes pretty fine how to work with Baselines, Configurations and GitHub.
http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht... <http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht...>
cheers! Esteban
ps: In fact, I would like to include it as âofficial documentationâ :P
On 25 Jan 2016, at 18:09, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
thanks,
Norbert
Maybe you can contribute to: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... and there are new chapters: https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgres... On Mon, Jan 25, 2016 at 6:09 PM, Norbert Hartl <norbert@hartl.name> wrote:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
thanks,
Norbert
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git: - I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore - I need to load metacello-work from github in order to use bitbucket:// repositories - Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code - Specifying a path to access a sub-directory of the repository seems not to be possible - I don't know where to specify credentials because I have a private repo on bitbucket My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right? Norbert
Hi Norbert, Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution). Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only. Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory. It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;) Thierry
Norbert
On 25 Jan 2016, at 20:45, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
⦠but is better to use it :) and yes, versionner needs to be adapted.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
not anymore, Pharo5 is updated. cheers! Esteban
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Thierry
Norbert
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error 'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. '
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see. Thanks again, Norbert
Hi Norbert, Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it? I haven't pushed the changes for the url syntax in that version. So the old syntax becomes: gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public. What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version. Thierry
Norbert
Hi Thierry,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
Yes.
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
Does not work for me. Same error.
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
It is a good approach. I guess the pharo code uses the library and the library uses ssh. And ssh inquires ssh-agent. Exactly as it should IMHO.
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
Why so? Because specifying the credentials is not possible?
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
To me it boils down to what you can utilize in jenkins.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
Good to hear. I'll test the development version then. thanks, Norbert
Le 25/01/2016 22:03, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
Yes.
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
Does not work for me. Same error.
I tried in Pharo3 and that works. Strange. Can you see what is missing from the git clone command when the error is raised? You should see a string or an array with the command almost complete.
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
It is a good approach. I guess the pharo code uses the library and the library uses ssh. And ssh inquires ssh-agent. Exactly as it should IMHO.
Agreed.
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
Why so? Because specifying the credentials is not possible?
Hum, because I don't really know to pass credentials unless by registering an ssh key. Mind you, I didn't really look into that :(
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
To me it boils down to what you can utilize in jenkins.
Just say how you would do that with something else and a git repository, and I think that can be reproduced or added. Thierry
Am 25.01.2016 um 22:19 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
I tried in Pharo3 and that works. Strange. Can you see what is missing from the git clone command when the error is raised? You should see a string or an array with the command almost complete.
I had a branch information added like gitfiletree://bitbucket.org/2denker/project:master?dir=st Without the :master it works Norbert
Le 25/01/2016 22:40, Norbert Hartl a écrit :
Am 25.01.2016 um 22:19 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
I tried in Pharo3 and that works. Strange. Can you see what is missing from the git clone command when the error is raised? You should see a string or an array with the command almost complete.
I had a branch information added like
gitfiletree://bitbucket.org/2denker/project:master?dir=st
Without the :master it works
Ok. It should have been gitfiletree://bitbucket.org/2denker/project?dir=st&branch=master Thierry
Norbert
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do ConfigurationOfGitFileTree loadDevelopment it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core. Norbert
Le 25/01/2016 22:12, Norbert Hartl a écrit :
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do
ConfigurationOfGitFileTree loadDevelopment
it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core.
:( I'll have a look. Thierry
Le 25/01/2016 22:12, Norbert Hartl a écrit :
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do
ConfigurationOfGitFileTree loadDevelopment
it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core.
Norbert
Hum, doing that (loading stable, installing something over gitfiletree, loading development) on a brand new Pharo4 image and I have no errors at all. Thierry
Hi Thierry,
Am 25.01.2016 um 22:28 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Le 25/01/2016 22:12, Norbert Hartl a écrit :
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do
ConfigurationOfGitFileTree loadDevelopment
it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core.
Norbert
Hum, doing that (loading stable, installing something over gitfiletree, loading development) on a brand new Pharo4 image and I have no errors at all.
Thank you very much. The shortest and most ui intensive way seems to be: - open fresh pharo - load only configuration from configuration browser - open versionner, click development and load version - Then the metacello command runs smoothly I'm thinking about creating a deployment user that has access to the repo and then add the credentials to the baseline url. That doesn't sound good but the access you need for the repo supersedes the access of the deployment user so for a closed project not too bad as long as SSL urls are used. Norbert
Hi Norbert, Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them. Thierry Le 25/01/2016 22:47, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 22:28 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Le 25/01/2016 22:12, Norbert Hartl a écrit :
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do
ConfigurationOfGitFileTree loadDevelopment
it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core.
Norbert
Hum, doing that (loading stable, installing something over gitfiletree, loading development) on a brand new Pharo4 image and I have no errors at all.
Thank you very much. The shortest and most ui intensive way seems to be:
- open fresh pharo - load only configuration from configuration browser - open versionner, click development and load version - Then the metacello command runs smoothly
I'm thinking about creating a deployment user that has access to the repo and then add the credentials to the baseline url. That doesn't sound good but the access you need for the repo supersedes the access of the deployment user so for a closed project not too bad as long as SSL urls are used.
Norbert
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like https://user:pass@bitbucket.org/â¦. I try that tomorrow. Norbert
Thierry
Le 25/01/2016 22:47, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 22:28 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Le 25/01/2016 22:12, Norbert Hartl a écrit :
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do
ConfigurationOfGitFileTree loadDevelopment
it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core.
Norbert
Hum, doing that (loading stable, installing something over gitfiletree, loading development) on a brand new Pharo4 image and I have no errors at all.
Thank you very much. The shortest and most ui intensive way seems to be:
- open fresh pharo - load only configuration from configuration browser - open versionner, click development and load version - Then the metacello command runs smoothly
I'm thinking about creating a deployment user that has access to the repo and then add the credentials to the baseline url. That doesn't sound good but the access you need for the repo supersedes the access of the deployment user so for a closed project not too bad as long as SSL urls are used.
Norbert
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/â¦.
I try that tomorrow.
But then I don't think that sub-directories work per http. Norbert
Norbert
Thierry
Le 25/01/2016 22:47, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 22:28 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Le 25/01/2016 22:12, Norbert Hartl a écrit :
Hi,
Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Le 25/01/2016 21:17, Norbert Hartl a écrit :
Hi Thierry,
Am 25.01.2016 um 20:45 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Le 25/01/2016 20:01, Norbert Hartl a écrit :
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
My own insights so far when using git:
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
You can use ConfigurationOf. BaselineOf is only there to help.
Ok, good to know.
- I need to load metacello-work from github in order to use bitbucket:// repositories
This should be an issue for Pharo.
- Metacello downloads a zip file from the repository to install code. I have no glue how I can download things locally in order to work on the code
Metacello github:// and bitbucket:// urls are only for read-only access to the packages (distribution).
Metacello install the contents of the zip into a path composed of github-cache (or bitbucket-cache I guess), the repository name, person name, commit id or version as a filetree repository. You can add that repository as a filetree repository inside Monticello if you want. But it is read-only.
That is ok if you produce a deployment artefact, e.g. with jenkins. But there is either a bitbucket:// _or_ a gitfiletree:// url in the baseline.
Download locally is done by either a git clone on the command line or by a GitFileTree remote repository addition.
- Specifying a path to access a sub-directory of the repository seems not to be possible
It is: url format is [github|gitfiletree|bitbucket]://.../repo:commit/sub-directory.
It works without sub-directory. With it throws an error
'Git error: Cloning into ''st''... conq: invalid command syntax. fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Oh, I see. You're using the stable version of GitFileTree in Pharo4, isn't it?
I haven't pushed the changes for the url syntax in that version. So the old syntax becomes:
gitfiletree://example.com/path/to/repo?dir=sub-directory&branch=commit
My problem is that the new url syntax is in the same package as the metadata-less mode of GitFileTree, and that mode supposes a fix to FileTree (a single method!). Maybe I'll switch the Pharo4 development version to not create metadata-less repositories.
It is also allways possible to reopen a filetree or a gitfiletree repo on a sub-directory of the main repository... this is how FileTree itself is tested for integration.
- I don't know where to specify credentials because I have a private repo on bitbucket
If you have a ssh key, then GitFileTree will pick it up for you.
Yes, that is my preferred way, too.
Well, that one really had to work :)
My conclusion is that if you don't want to use versionner and you have public projects on github using that stuff might seem feasible. If any of those is different it won't work. Right?
No, it works and has been working for git access to private repositories, bitbucket included, for years... at least on Linux ;)
Ok, thanks, if the sub-directory stuff would work it would be ok to jump in. Maybe there is a way to tweak the url in the baseline. It would remove the need to install gitfiletree in a deployment artefact. We'll see.
In a deployment artefact, then it becomes a bit different because your repo is then public.
What I did for a Pharo4 deployment was to write a context dependent Makefile which uses filetree if I'm dealing with an archive of my artefact, and gitfiletree if it is build from a development repo.
Thanks again,
You're welcome. I'll update GitFileTree for Pharo4 soon and recommend that you use the development version.
If I have installed stable version and do
ConfigurationOfGitFileTree loadDevelopment
it breaks zinc and the image is unusable :) Looks like a modification in Zinc-Resource-Meta-Core.
Norbert
Hum, doing that (loading stable, installing something over gitfiletree, loading development) on a brand new Pharo4 image and I have no errors at all.
Thank you very much. The shortest and most ui intensive way seems to be:
- open fresh pharo - load only configuration from configuration browser - open versionner, click development and load version - Then the metacello command runs smoothly
I'm thinking about creating a deployment user that has access to the repo and then add the credentials to the baseline url. That doesn't sound good but the access you need for the repo supersedes the access of the deployment user so for a closed project not too bad as long as SSL urls are used.
Norbert
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url, gitfiletree://user:pass@bitbucket.org/...?protocol=https I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh. Thierry
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https <gitfiletree://user:pass@bitbucket.org/...?protocol=https>
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well. Norbert
On 26 Jan 2016, at 13:03, Norbert Hartl <norbert@hartl.name> wrote:
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I am only following this discussion from the sidelines, but I just wanted to say that the URL above parses correctly without problems: This is in Pharo 4, with the following relevant package: Name: Zinc-Resource-Meta-Core-PavelKrivanek.56 Author: PavelKrivanek Time: 30 October 2015, 11:36:17.550123 am UUID: 8a7851bd-d01d-4943-b929-ec85436de54f Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.55 I haven't seen your stack trace of course, but it should work. Sven
Hi, using the bitbucket:// scheme and authority leads to a download url of https://bitbucket.org/NorbertHartl/get/<password>@2denker.zip where NorbertHartl and <password> are the credentials and 2denker is the user. The project name is stripped off. So this does not work as expected. Norbert
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/ <https://user:pass@bitbucket.org/>â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https <gitfiletree://user:pass@bitbucket.org/...?protocol=https>
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Norbert
"I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual." Searching "pharo git" on youtube bring my video tutorial top on the list of search results "https://www.youtube.com/results?search_query=pharo+git" On Tue, Jan 26, 2016 at 2:27 PM Norbert Hartl <norbert@hartl.name> wrote:
Hi,
using the bitbucket:// scheme and authority leads to a download url of
https://bitbucket.org/NorbertHartl/get/<password>@2denker.zip
where NorbertHartl and <password> are the credentials and 2denker is the user. The project name is stripped off.
So this does not work as expected.
Norbert
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com
:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com
:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Norbert
Thanks. To be honest I don't watch videos if I want something to know. So I skip those nearly always. Your tutorial (didn't watch) seems to be about github and sourcetree. So it does not seem to touch any of my problems. Norbert
Am 26.01.2016 um 13:31 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
"I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual."
Searching "pharo git" on youtube bring my video tutorial top on the list of search results "https://www.youtube.com/results?search_query=pharo+git <https://www.youtube.com/results?search_query=pharo+git>"
On Tue, Jan 26, 2016 at 2:27 PM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: Hi,
using the bitbucket:// scheme and authority leads to a download url of
https://bitbucket.org/NorbertHartl/get/<password>@2denker.zip <https://bitbucket.org/NorbertHartl/get/%3Cpassword%3E@2denker.zip>
where NorbertHartl and <password> are the credentials and 2denker is the user. The project name is stripped off.
So this does not work as expected.
Norbert
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/ <https://user:pass@bitbucket.org/>â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https <>
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Norbert
fair enough, its obviously your choice, but please note that text documentation is slowly dying. And no I am not talking about Pharo documentation. As you probably aware of , book sales have plummeted the last decade that adsl connection speed has been rapidly rising. So there is not even a comparison between the quantity and quality of video tutorials compared to text tutorial which we see a very steady decline. Even University who have taken their courses online have solely preferred the video format to text documentation, although you can still get some text documentation for reference purposes. My video tutorial explain the whole process of working pharo with git, to my knowledge is the only tutorial that does this, it takes from how to do things with filetree, how to use baselines (i think I included that one but my connection is down and I cant check this) , how to use git (contrary to other pharo git documentation that assumes knowledge of git) and how to use an external gui client (something I highly recommend because there is no replacement for it with pharo ) . Sourcetree is used as an example , you can use any other git gui client instead. I chose not to present gitfiletree because at the time it had problem on both MacOS and Windows, dont know if Thierry has fixed those issues. On Tue, Jan 26, 2016 at 2:46 PM Norbert Hartl <norbert@hartl.name> wrote:
Thanks.
To be honest I don't watch videos if I want something to know. So I skip those nearly always. Your tutorial (didn't watch) seems to be about github and sourcetree. So it does not seem to touch any of my problems.
Norbert
Am 26.01.2016 um 13:31 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
"I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual."
Searching "pharo git" on youtube bring my video tutorial top on the list of search results "https://www.youtube.com/results?search_query=pharo+git"
On Tue, Jan 26, 2016 at 2:27 PM Norbert Hartl <norbert@hartl.name> wrote:
Hi,
using the bitbucket:// scheme and authority leads to a download url of
https://bitbucket.org/NorbertHartl/get/<password>@2denker.zip
where NorbertHartl and <password> are the credentials and 2denker is the user. The project name is stripped off.
So this does not work as expected.
Norbert
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com
:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com
:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Norbert
I forgot to add that I will create a new tutorial that will contain how to get the git project added to Package Browser and generally update the workflow, but I am waiting for testing also meta-data less gitfiletree and see if gitfiletree fixes its problems on macos at least ( unfortunately SubprocessOS does not currently work on Windows which is what I think gitfiletree tries to port to to fix the issues on macos). On Tue, Jan 26, 2016 at 3:07 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote:
fair enough, its obviously your choice, but please note that text documentation is slowly dying. And no I am not talking about Pharo documentation.
As you probably aware of , book sales have plummeted the last decade that adsl connection speed has been rapidly rising. So there is not even a comparison between the quantity and quality of video tutorials compared to text tutorial which we see a very steady decline. Even University who have taken their courses online have solely preferred the video format to text documentation, although you can still get some text documentation for reference purposes.
My video tutorial explain the whole process of working pharo with git, to my knowledge is the only tutorial that does this, it takes from how to do things with filetree, how to use baselines (i think I included that one but my connection is down and I cant check this) , how to use git (contrary to other pharo git documentation that assumes knowledge of git) and how to use an external gui client (something I highly recommend because there is no replacement for it with pharo ) . Sourcetree is used as an example , you can use any other git gui client instead. I chose not to present gitfiletree because at the time it had problem on both MacOS and Windows, dont know if Thierry has fixed those issues.
On Tue, Jan 26, 2016 at 2:46 PM Norbert Hartl <norbert@hartl.name> wrote:
Thanks.
To be honest I don't watch videos if I want something to know. So I skip those nearly always. Your tutorial (didn't watch) seems to be about github and sourcetree. So it does not seem to touch any of my problems.
Norbert
Am 26.01.2016 um 13:31 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
"I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual."
Searching "pharo git" on youtube bring my video tutorial top on the list of search results "https://www.youtube.com/results?search_query=pharo+git"
On Tue, Jan 26, 2016 at 2:27 PM Norbert Hartl <norbert@hartl.name> wrote:
Hi,
using the bitbucket:// scheme and authority leads to a download url of
https://bitbucket.org/NorbertHartl/get/<password>@2denker.zip
where NorbertHartl and <password> are the credentials and 2denker is the user. The project name is stripped off.
So this does not work as expected.
Norbert
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier < thierry.goubier@gmail.com>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier < thierry.goubier@gmail.com>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Norbert
Dimitris,
Am 26.01.2016 um 14:07 schrieb Dimitris Chloupis <kilon.alios@gmail.com>:
fair enough, its obviously your choice, but please note that text documentation is slowly dying. And no I am not talking about Pharo documentation.
I don't really believe the text documentation is dying because I haven't seen a replacement for it. Even if it is dying I could decline that and prefer text documentation, no? :)
As you probably aware of , book sales have plummeted the last decade that adsl connection speed has been rapidly rising. So there is not even a comparison between the quantity and quality of video tutorials compared to text tutorial which we see a very steady decline. Even University who have taken their courses online have solely preferred the video format to text documentation, although you can still get some text documentation for reference purposes.
I don't think book sales are an indicator for the health of the text domain. The medium is dying not things being text. One of the main reasons I don't like videos is because skipping is too complicated. I needed 10 times clicking my mouse to skip the first 3:30 of your video because I'm neither interested in github nor in sourcetree this time.
My video tutorial explain the whole process of working pharo with git, to my knowledge is the only tutorial that does this, it takes from how to do things with filetree, how to use baselines (i think I included that one but my connection is down and I cant check this) , how to use git (contrary to other pharo git documentation that assumes knowledge of git) and how to use an external gui client (something I highly recommend because there is no replacement for it with pharo ) . Sourcetree is used as an example , you can use any other git gui client instead. I chose not to present gitfiletree because at the time it had problem on both MacOS and Windows, dont know if Thierry has fixed those issues.
You are telling me I should watch the video but I got the impression you didn't read any of this thread before replying ;) Your video is not about the problems I have. It is a beginner video how to use pharo and git together and that's fine. I'm glad you did it. I'm after a workflow that can be used as developer as well as in a continuous integration server without introducing to many side effects. thanks, Norbert
On Tue, Jan 26, 2016 at 2:46 PM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: Thanks.
To be honest I don't watch videos if I want something to know. So I skip those nearly always. Your tutorial (didn't watch) seems to be about github and sourcetree. So it does not seem to touch any of my problems.
Norbert
Am 26.01.2016 um 13:31 schrieb Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>>:
"I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual."
Searching "pharo git" on youtube bring my video tutorial top on the list of search results "https://www.youtube.com/results?search_query=pharo+git <https://www.youtube.com/results?search_query=pharo+git>"
On Tue, Jan 26, 2016 at 2:27 PM Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote: Hi,
using the bitbucket:// scheme and authority leads to a download url of
https://bitbucket.org/NorbertHartl/get/<password>@2denker.zip <https://bitbucket.org/NorbertHartl/get/%3Cpassword%3E@2denker.zip>
where NorbertHartl and <password> are the credentials and 2denker is the user. The project name is stripped off.
So this does not work as expected.
Norbert
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/ <https://user:pass@bitbucket.org/>â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https <>
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Norbert
Le 26/01/2016 14:07, Dimitris Chloupis a écrit :
fair enough, its obviously your choice, but please note that text documentation is slowly dying. And no I am not talking about Pharo documentation.
I do not agree on that point. Myself and a lot of my friends use text documentation way more than videos. Maybe you see more video documentation because you work in visual stuff/3D. Graphical artists are more incline to use visual documentation as video. But in general, most of the people I know check a video to get a global view of something then use textual documentation when they really want to learn. And I think this is better to learn because you can go with your own rhythm. But with a video it's harder. The rhythm is imposed.
As you probably aware of , book sales have plummeted the last decade that adsl connection speed has been rapidly rising. So there is not even a comparison between the quantity and quality of video tutorials compared to text tutorial which we see a very steady decline. Even University who have taken their courses online have solely preferred the video format to text documentation, although you can still get some text documentation for reference purposes.
My video tutorial explain the whole process of working pharo with git, to my knowledge is the only tutorial that does this, it takes from how to do things with filetree, how to use baselines (i think I included that one but my connection is down and I cant check this) , how to use git (contrary to other pharo git documentation that assumes knowledge of git) and how to use an external gui client (something I highly recommend because there is no replacement for it with pharo ) . Sourcetree is used as an example , you can use any other git gui client instead. I chose not to present gitfiletree because at the time it had problem on both MacOS and Windows, dont know if Thierry has fixed those issues.
-- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
"You are telling me I should watch the video but I got the impression you didn't read any of this thread before replying ;) Your video is not about the problems I have. It is a beginner video how to use pharo and git together and that's fine. I'm glad you did it. I'm after a workflow that can be used as developer as well as in a continuous integration server without introducing to many side effects. thanks, Norbert" The problem is that both of your problems are not directly related to git, Configurations and CI. Somewhate related yes but not directly. Configurations are not that related because git and github are more than capable into creating their own versions and their own releases and thank you for touching this subject because i want to mention it in my future video tutorial on pharo git. Git has several ways of doing this , git tags or branches, while github adds releases also to that. The nice thing about git and github is that it allow you to included also external assets, like images, sounds, pdf, database files , any kind of file into your repo. But you can also keep files outside the repo and still make github releases with them, since github releases can contain external assets that do not belong to the repo together with the repo in a single ZIP file. So this is why we use Baseline and not Configurations when we work with git. You will be correct to note that my video tutorial does not touch that part and that is more begineer orientated, but then that is easy for me to explain on a future video tutorial. CI is another tool altgother, git is for version control, CI is for project automatic packaging. It allow you to pull a repo from a git or any other kind of repo and run some tests on it and then build it or do all sort of stuff on it before packaging together. Its a whole another chapter on itself and a whole new set of video tutorials and my video wont help you there, because CI is not related to git and if I made a video tutorial how to use pharo + git with CI , it would have been a CI video tutorial and NOT a pharo+git tutorial. " I do not agree on that point. Myself and a lot of my friends use text documentation way more than videos. Maybe you see more video documentation because you work in visual stuff/3D. Graphical artists are more incline to use visual documentation as video." Definitely not the reason. I don't disagree with you that most people would prefer to have text documentation to video documentation. The nice thing about text documentation is easier to seek through and find what you want. But documentation is not dictated by its users but rather its creators. Video tutorial are far , far , far easier to make. Thus why they have exploded in popularity. To give you an example, lately I am learning C++ and looking into a specific kind of IPC. IPC has nothing to do with 3d graphics its Inter Process Communication, its what I use to make pharo talk to python with sockets. Now I am investigating the fastest form of IPC, shared memory and the most popular implementation of shared memory, memory mapped files. Its just a file that is uploaded to a part of the memory that then can be shared among diffirent applications (processes) and you dont have to move data around like you do with sockets and of course its a million times faster since its just direct memory manipulation with pointers. I wont even begin to describe my surprise about lack of documentation , text documentation about such a basic subject. Examples I found were mostly C and Linux and I was searching C++ and Macos. I go youtube, BOOM! tons of tutorials most of them the past year or two compared to very dated text documentation (my best bet are blog posts for up to date info). Messing around youtube with shared memory I found OpenMP shared memory, no idea what that was, I use google to search what the hell that is, reading website description about parrelism , makes a bit sense, but I want to know more, trying to find documentation same website recommend me to go back to YouTube to watch video tutorial by one of the dudes that made OpenMP. I have read text docs about threads in the past with python , the irony is that his video tutorial even though in C and using far more complex concepts are much easier to understand follow. And this is no small library made by a random guy this freaking Intel and OpenMP is probably the most popular library for multi threading currently and parrarely programming. I can go on, C++ 11 docs , youtube wins hands down, QT docs, youtube winds hands down , pretty much any python library you can imagine , youtube wins hands down. Even I , prefer text documentation to video tutorials . I downloaded the OpenMP pdf spec as I have pdfs for many libraries , QT , python etc. But I am forced to use YouTube more and more because hands down is by far the best resource of modern documentation, there is no comparison. And as documentation creator I have to confess I prefer making video tutorials 10 times more than writting text because, well I am lazy and its just way way way easier. On Tue, Jan 26, 2016 at 3:56 PM Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Le 26/01/2016 14:07, Dimitris Chloupis a écrit :
fair enough, its obviously your choice, but please note that text documentation is slowly dying. And no I am not talking about Pharo documentation.
I do not agree on that point. Myself and a lot of my friends use text documentation way more than videos.
Maybe you see more video documentation because you work in visual stuff/3D. Graphical artists are more incline to use visual documentation as video.
But in general, most of the people I know check a video to get a global view of something then use textual documentation when they really want to learn. And I think this is better to learn because you can go with your own rhythm. But with a video it's harder. The rhythm is imposed.
As you probably aware of , book sales have plummeted the last decade that adsl connection speed has been rapidly rising. So there is not even a comparison between the quantity and quality of video tutorials compared to text tutorial which we see a very steady decline. Even University who have taken their courses online have solely preferred the video format to text documentation, although you can still get some text documentation for reference purposes.
My video tutorial explain the whole process of working pharo with git, to my knowledge is the only tutorial that does this, it takes from how to do things with filetree, how to use baselines (i think I included that one but my connection is down and I cant check this) , how to use git (contrary to other pharo git documentation that assumes knowledge of git) and how to use an external gui client (something I highly recommend because there is no replacement for it with pharo ) . Sourcetree is used as an example , you can use any other git gui client instead. I chose not to present gitfiletree because at the time it had problem on both MacOS and Windows, dont know if Thierry has fixed those issues.
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/ <https://user:pass@bitbucket.org/>â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https <gitfiletree://user:pass@bitbucket.org/...?protocol=https>
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Ok, I got it through the unknown url scheme but indeed the credentials are stripped off. Norbert
2016-01-26 13:32 GMT+01:00 Norbert Hartl <norbert@hartl.name>:
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com
:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com
:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
https://user:pass@bitbucket.org/â¦.
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Ok, I got it through the unknown url scheme but indeed the credentials are stripped off.
I'll implement something later today. Thierry
Norbert
Hi Norbert, the development version on Pharo4 has the credentials working now. It switches to https instead of ssh if you add a username and a password, since a ssh url can't carry a password and, in the case of github, the ssh user is allways git. Thierry Le 26/01/2016 13:32, Norbert Hartl a écrit :
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Ok, I got it through the unknown url scheme but indeed the credentials are stripped off.
Norbert
Hi Thierry,
Am 27.01.2016 um 06:40 schrieb Thierry Goubier <thierry.goubier@gmail.com>:
Hi Norbert,
the development version on Pharo4 has the credentials working now. It switches to https instead of ssh if you add a username and a password, since a ssh url can't carry a password and, in the case of github, the ssh user is allways git.
thanks very much. I need to find some time to try it out. I have kind of a workflow but that does only work if I use a single repository. Norbert
Thierry
Le 26/01/2016 13:32, Norbert Hartl a écrit :
Am 26.01.2016 um 13:03 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Am 25.01.2016 um 23:32 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 25/01/2016 23:13, Norbert Hartl a écrit :
Am 25.01.2016 um 23:02 schrieb Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>>:
Hi,
Am 25.01.2016 um 22:55 schrieb Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Hi Norbert,
Just tell me if you need any additional parameter to the git clone for the credentials, because I'm not sure I have written the code which will handle them.
I'll check that. The easiest approach is to use the authority part of the url like
I'm nearly sure my code doesn't check for them and silently drop them :(
I try that tomorrow.
But then I don't think that sub-directories work per http.
They do over https. But remember the syntax is, to take your url,
gitfiletree://user:pass@bitbucket.org/...?protocol=https
Does not work for me. It complains about unknown url scheme. But using the read-only version of gitfiletree would still mean I have to install gitfiletree, no? I have no glue hot the url with bitbucket:// could work.
I wonder if I can write code that considers that if you have a username and a password, then it should use https and not ssh.
I see no reason why. You can use ssh with username and password as well.
Ok, I got it through the unknown url scheme but indeed the credentials are stripped off.
Norbert
Hi Norbert, the latest development version of GitFileTree for Pharo4 has the new url syntax and does not create metadata-less repositories by default. Thierry
NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/ ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Am 26.01.2016 um 15:11 schrieb Sean P. DeNigris <sean@clipperadams.com>:
NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
same here Norbert
2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it. Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side. But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo. On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <thierry.goubier@gmail.com> wrote:
2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>:
NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side.
But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo.
No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text. (This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.)
On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <thierry.goubier@gmail.com> wrote: 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works. I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around. Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design. Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is". So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware". Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island. And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world. "Git just manages blobs, text files at best. Dead text" Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code. Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway. On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side.
But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo.
No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text.
(This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.)
On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier < thierry.goubier@gmail.com> wrote: 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works.
I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around.
Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design.
Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is".
So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware".
Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island.
And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world.
"Git just manages blobs, text files at best. Dead text"
Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code.
Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway.
Yes and no. If git compares two versions, it does not understand what is in it. When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them. Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment. The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position. When have you last looked at the source code of git ? And be honest, do you find git always easy to use ?
On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side.
But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo.
No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text.
(This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.)
On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <thierry.goubier@gmail.com> wrote: 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
"If git compares two versions, it does not understand what is in it." why it should ? its a version control system, not a refactoring tool. " When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them." is that Monticello or is that refactoring classes and methods of pharo ? Because the way I see it is like this if you have a refactoring language, a language that can refactor its own code , that language should be able to take two diffirent pieces of code and not only show you a diff but also show you how your inheritance is affected, your classes even your live state. The big question here, from my side is why a version control system should do that ? Refactoring and version controlling for me at least is two very different tasks. I dont also see how a version control system that is self aware refactoring wise when already have refactoring tools in my IDE, is giving me any advantage me as a user. Most IDEs come with them anyway. Its not as if you will use a python IDE, or whatever language you use and the IDE will go "sorry dude I cannot tell you what git did there because it has no refactoring and I am too stupid to use my own refactoring tools". That IDE would belong to the bin. This is why we use specialized Git gui tools, they are not there just to make our screens pretty. "Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment." What you lose is the live state which monticello does not store anyway, how could it ? it only stores text files, its actually far more anti-Smalltalk than git is. Because with git you can version control your pharo images or your fuel files than contain the live state or you could export the live state and live code to a binary file. Now try that with monticello. The irony is very large, Git is far more Smalltalk friendly, than Monticello is. "The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position." I completely agree in the end every API ever programm is to a degree an island. No code ever shakes in terror saying "oh my god I need to make my code 100% compatible with whatever is out there" . Its not possible. But the culture of those other languages is "lets keep things close" , "lets make coder's life" easier , "lets keep compatibility and standard/common practices" . Smalltalk does not do that because it loves experimentation, the whole smalltalk enviroment is experimentation heaven playground. Thats great because without it we dont have smalltalk but its also bad. "When have you last looked at the source code of git ?" Never ? Why should I, I dont even take a look at monticello source code. I tried to improve auto completion and my head kept spinning around and around, 10s of hours still could not figure out the code. I am not smart or knowledgable to judge Monticello on a source code basis. Maybe source code wise, core wise, Monticello is 1000 times better than Git, but my complains with Monticello is on the user level. As a smalltalker I just dont see the point of prefering Monticello over Git , or screw Git, you want mercurial ? thats fine too. I just dont see it whats the big deal with Monticello. "And be honest, do you find git always easy to use ?" I have been honest from the very start when I started pushing for git and Github. I have been crystal clear. My usage of git is super simple. I dont work in teams, I work alone, I dont even use branches, I do git pull, git add, git commit and git push. I have reverted commits a couple of times, I have reset to head sometimes because of some nasty merges and that was it. I am almost never have merge conflicts. You want me to compare my experience with monticello and StHub VS git and Github using Pharo ? Nope you dont. Do I find git always easy to use ? You know what , I am a python coder and I definetly appreciate ease of use and simplicity but lets be frank here Git was made by the same guy that made the freaking Linux kernel. He made Git not to be easy but able to manage an enormous amount of code the easy way the fastest possible way and he accomplished that goal. So do I find git easy to use ? Nope Do I care ? Nope, because I rather use something that is difficult to use but powerful and with good performance than something that is very easy to use , limited and slow. Hell , I dont even find Pharo easy to use , its power and flexibility that made me love it. On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works.
I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around.
Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design.
Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is".
So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware".
Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island.
And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world.
"Git just manages blobs, text files at best. Dead text"
Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code.
Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway.
Yes and no.
If git compares two versions, it does not understand what is in it.
When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them.
Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment.
The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position.
When have you last looked at the source code of git ?
And be honest, do you find git always easy to use ?
On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side.
But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo.
No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text.
(This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.)
On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier < thierry.goubier@gmail.com> wrote: 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Sometimes I really don't understand what you see in Pharo ...
On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
"If git compares two versions, it does not understand what is in it."
why it should ? its a version control system, not a refactoring tool.
" When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them."
is that Monticello or is that refactoring classes and methods of pharo ? Because the way I see it is like this if you have a refactoring language, a language that can refactor its own code , that language should be able to take two diffirent pieces of code and not only show you a diff but also show you how your inheritance is affected, your classes even your live state.
The big question here, from my side is why a version control system should do that ? Refactoring and version controlling for me at least is two very different tasks. I dont also see how a version control system that is self aware refactoring wise when already have refactoring tools in my IDE, is giving me any advantage me as a user. Most IDEs come with them anyway.
Its not as if you will use a python IDE, or whatever language you use and the IDE will go "sorry dude I cannot tell you what git did there because it has no refactoring and I am too stupid to use my own refactoring tools". That IDE would belong to the bin. This is why we use specialized Git gui tools, they are not there just to make our screens pretty.
"Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment."
What you lose is the live state which monticello does not store anyway, how could it ? it only stores text files, its actually far more anti-Smalltalk than git is. Because with git you can version control your pharo images or your fuel files than contain the live state or you could export the live state and live code to a binary file. Now try that with monticello. The irony is very large, Git is far more Smalltalk friendly, than Monticello is.
"The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position."
I completely agree in the end every API ever programm is to a degree an island. No code ever shakes in terror saying "oh my god I need to make my code 100% compatible with whatever is out there" . Its not possible. But the culture of those other languages is "lets keep things close" , "lets make coder's life" easier , "lets keep compatibility and standard/common practices" .
Smalltalk does not do that because it loves experimentation, the whole smalltalk enviroment is experimentation heaven playground. Thats great because without it we dont have smalltalk but its also bad.
"When have you last looked at the source code of git ?"
Never ? Why should I, I dont even take a look at monticello source code. I tried to improve auto completion and my head kept spinning around and around, 10s of hours still could not figure out the code. I am not smart or knowledgable to judge Monticello on a source code basis. Maybe source code wise, core wise, Monticello is 1000 times better than Git, but my complains with Monticello is on the user level. As a smalltalker I just dont see the point of prefering Monticello over Git , or screw Git, you want mercurial ? thats fine too.
I just dont see it whats the big deal with Monticello.
"And be honest, do you find git always easy to use ?"
I have been honest from the very start when I started pushing for git and Github. I have been crystal clear. My usage of git is super simple.
I dont work in teams, I work alone, I dont even use branches, I do git pull, git add, git commit and git push. I have reverted commits a couple of times, I have reset to head sometimes because of some nasty merges and that was it. I am almost never have merge conflicts.
You want me to compare my experience with monticello and StHub VS git and Github using Pharo ? Nope you dont.
Do I find git always easy to use ? You know what , I am a python coder and I definetly appreciate ease of use and simplicity but lets be frank here Git was made by the same guy that made the freaking Linux kernel. He made Git not to be easy but able to manage an enormous amount of code the easy way the fastest possible way and he accomplished that goal.
So do I find git easy to use ? Nope
Do I care ? Nope, because I rather use something that is difficult to use but powerful and with good performance than something that is very easy to use , limited and slow. Hell , I dont even find Pharo easy to use , its power and flexibility that made me love it.
On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works.
I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around.
Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design.
Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is".
So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware".
Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island.
And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world.
"Git just manages blobs, text files at best. Dead text"
Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code.
Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway.
Yes and no.
If git compares two versions, it does not understand what is in it.
When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them.
Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment.
The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position.
When have you last looked at the source code of git ?
And be honest, do you find git always easy to use ?
On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side.
But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo.
No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text.
(This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.)
On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <thierry.goubier@gmail.com> wrote: 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I love live coding , dynamic language, beautiful syntax and close integration with IDE. But yeah Monticello , I don't get it. I love Pharo and always respect the hard work of others but that does not mean I love every part of it. Same story is Blender , Python and all other tools I use. That ok I don't worry if some parts I don't like. It's what make with the tools you have that matters most. On Tue, 26 Jan 2016 at 19:46, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Sometimes I really don't understand what you see in Pharo ...
On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
"If git compares two versions, it does not understand what is in it."
why it should ? its a version control system, not a refactoring tool.
" When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them."
is that Monticello or is that refactoring classes and methods of pharo ? Because the way I see it is like this if you have a refactoring language, a language that can refactor its own code , that language should be able to take two diffirent pieces of code and not only show you a diff but also show you how your inheritance is affected, your classes even your live state.
The big question here, from my side is why a version control system should do that ? Refactoring and version controlling for me at least is two very different tasks. I dont also see how a version control system that is self aware refactoring wise when already have refactoring tools in my IDE, is giving me any advantage me as a user. Most IDEs come with them anyway.
Its not as if you will use a python IDE, or whatever language you use and the IDE will go "sorry dude I cannot tell you what git did there because it has no refactoring and I am too stupid to use my own refactoring tools". That IDE would belong to the bin. This is why we use specialized Git gui tools, they are not there just to make our screens pretty.
"Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment."
What you lose is the live state which monticello does not store anyway, how could it ? it only stores text files, its actually far more anti-Smalltalk than git is. Because with git you can version control your pharo images or your fuel files than contain the live state or you could export the live state and live code to a binary file. Now try that with monticello. The irony is very large, Git is far more Smalltalk friendly, than Monticello is.
"The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position."
I completely agree in the end every API ever programm is to a degree an island. No code ever shakes in terror saying "oh my god I need to make my code 100% compatible with whatever is out there" . Its not possible. But the culture of those other languages is "lets keep things close" , "lets make coder's life" easier , "lets keep compatibility and standard/common practices" .
Smalltalk does not do that because it loves experimentation, the whole smalltalk enviroment is experimentation heaven playground. Thats great because without it we dont have smalltalk but its also bad.
"When have you last looked at the source code of git ?"
Never ? Why should I, I dont even take a look at monticello source code. I tried to improve auto completion and my head kept spinning around and around, 10s of hours still could not figure out the code. I am not smart or knowledgable to judge Monticello on a source code basis. Maybe source code wise, core wise, Monticello is 1000 times better than Git, but my complains with Monticello is on the user level. As a smalltalker I just dont see the point of prefering Monticello over Git , or screw Git, you want mercurial ? thats fine too.
I just dont see it whats the big deal with Monticello.
"And be honest, do you find git always easy to use ?"
I have been honest from the very start when I started pushing for git and Github. I have been crystal clear. My usage of git is super simple.
I dont work in teams, I work alone, I dont even use branches, I do git pull, git add, git commit and git push. I have reverted commits a couple of times, I have reset to head sometimes because of some nasty merges and that was it. I am almost never have merge conflicts.
You want me to compare my experience with monticello and StHub VS git and Github using Pharo ? Nope you dont.
Do I find git always easy to use ? You know what , I am a python coder and I definetly appreciate ease of use and simplicity but lets be frank here Git was made by the same guy that made the freaking Linux kernel. He made Git not to be easy but able to manage an enormous amount of code the easy way the fastest possible way and he accomplished that goal.
So do I find git easy to use ? Nope
Do I care ? Nope, because I rather use something that is difficult to use but powerful and with good performance than something that is very easy to use , limited and slow. Hell , I dont even find Pharo easy to use , its power and flexibility that made me love it.
On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works.
I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around.
Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design.
Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is".
So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware".
Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island.
And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world.
"Git just manages blobs, text files at best. Dead text"
Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code.
Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway.
Yes and no.
If git compares two versions, it does not understand what is in it.
When Monticello compares versions, it knows about classes, methods, inheritance, it can explain diffs in the same structured (browsable) form that you wrote them.
Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment.
The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position.
When have you last looked at the source code of git ?
And be honest, do you find git always easy to use ?
On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side.
But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo.
No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text.
(This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.)
On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier < thierry.goubier@gmail.com> wrote: 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com>: NorbertHartl wrote
- I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use Versionner anymore
Unfortunately. This is the biggest drag for me after switching all my personal projects to git (GitHub for public and BitBucket for private). I had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like going back to the dark ages :/
Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it.
Thierry
----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
For me what monticello has and git not is that is unobtrusive. Yes interface is not pretty, but once you have the basics it becomes invisible. Not the case with git. Hopefully the DVCS support will have the same amount of invisibility. I know that now things are moving, but long threads about the integration of git + pharo show the responsiveness of the community in one hand and the lot of support it needs for working on the other. Cheers, Offray On 26/01/16 13:10, Dimitris Chloupis wrote:
I love live coding , dynamic language, beautiful syntax and close integration with IDE. But yeah Monticello , I don't get it. I love Pharo and always respect the hard work of others but that does not mean I love every part of it. Same story is Blender , Python and all other tools I use. That ok I don't worry if some parts I don't like. It's what make with the tools you have that matters most. On Tue, 26 Jan 2016 at 19:46, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote:
Sometimes I really don't understand what you see in Pharo ...
> On 26 Jan 2016, at 17:53, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > "If git compares two versions, it does not understand what is in it." > > why it should ? its a version control system, not a refactoring tool. > > " > When Monticello compares versions, it knows about classes, methods, inheritance, > it can explain diffs in the same structured (browsable) form that you wrote them." > > is that Monticello or is that refactoring classes and methods of pharo ? Because the way I see it is like this if you have a refactoring language, a language that can refactor its own code , that language should be able to take two diffirent pieces of code and not only show you a diff but also show you how your inheritance is affected, your classes even your live state. > > The big question here, from my side is why a version control system should do that ? Refactoring and version controlling for me at least is two very different tasks. I dont also see how a version control system that is self aware refactoring wise when already have refactoring tools in my IDE, is giving me any advantage me as a user. Most IDEs come with them anyway. > > Its not as if you will use a python IDE, or whatever language you use and the IDE will go "sorry dude I cannot tell you what git did there because it has no refactoring and I am too stupid to use my own refactoring tools". That IDE would belong to the bin. This is why we use specialized Git gui tools, they are not there just to make our screens pretty. > > "Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment." > > What you lose is the live state which monticello does not store anyway, how could it ? it only stores text files, its actually far more anti-Smalltalk than git is. Because with git you can version control your pharo images or your fuel files than contain the live state or you could export the live state and live code to a binary file. Now try that with monticello. The irony is very large, Git is far more Smalltalk friendly, than Monticello is. > > "The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position." > > I completely agree in the end every API ever programm is to a degree an island. No code ever shakes in terror saying "oh my god I need to make my code 100% compatible with whatever is out there" . Its not possible. But the culture of those other languages is "lets keep things close" , "lets make coder's life" easier , "lets keep compatibility and standard/common practices" . > > Smalltalk does not do that because it loves experimentation, the whole smalltalk enviroment is experimentation heaven playground. Thats great because without it we dont have smalltalk but its also bad. > > "When have you last looked at the source code of git ?" > > Never ? Why should I, I dont even take a look at monticello source code. I tried to improve auto completion and my head kept spinning around and around, 10s of hours still could not figure out the code. I am not smart or knowledgable to judge Monticello on a source code basis. Maybe source code wise, core wise, Monticello is 1000 times better than Git, but my complains with Monticello is on the user level. As a smalltalker I just dont see the point of prefering Monticello over Git , or screw Git, you want mercurial ? thats fine too. > > I just dont see it whats the big deal with Monticello. > > "And be honest, do you find git always easy to use ?" > > I have been honest from the very start when I started pushing for git and Github. I have been crystal clear. My usage of git is super simple. > > I dont work in teams, I work alone, I dont even use branches, I do git pull, git add, git commit and git push. I have reverted commits a couple of times, I have reset to head sometimes because of some nasty merges and that was it. I am almost never have merge conflicts. > > You want me to compare my experience with monticello and StHub VS git and Github using Pharo ? Nope you dont. > > Do I find git always easy to use ? You know what , I am a python coder and I definetly appreciate ease of use and simplicity but lets be frank here Git was made by the same guy that made the freaking Linux kernel. He made Git not to be easy but able to manage an enormous amount of code the easy way the fastest possible way and he accomplished that goal. > > So do I find git easy to use ? Nope > > Do I care ? Nope, because I rather use something that is difficult to use but powerful and with good performance than something that is very easy to use , limited and slow. Hell , I dont even find Pharo easy to use , its power and flexibility that made me love it. > > > On Tue, Jan 26, 2016 at 6:23 PM Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: > > > On 26 Jan 2016, at 16:49, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > > > Obviously it will better fit Pharo since its made to work with smalltalk code, but that does not make it any less terrible. Just because you have one implementation of something that does not mean its good. Its just means its there and it works. > > > > I dont know the internal, they are not documented anyway, there are some class comments here and there but thats pretty much it. I dont even remember when was the last time monticello got an updated, I mean a serious update not just a couple of bug fixes the 2 years I have been around. > > > > Secondly GUI is just plain awful, Smalltalk maybe be the first or one of the first to implement guis, but those implementations never ended up to something that would be approachable and easy to use on a day to day basis, some tools suffer more from this some less, Monticello is up there with the worse design. > > > > Thirdly the inability of the system to version control images , audio files and other assets it defeats the central purpose of smalltalk of everything being objects with a loud "Nope !" from Monticello "Only source code is". > > > > So its awesome that Smalltalk , and Squeak got its own version control system, that is easy to use and Pharo inherited it. Congratulations to people behind it. But the GUI needs to go, its a bad advertisement to Pharo, and we need something that is not stuck to dark ages as you correctly pointed but for the opposite reason. Because any way you try to turn Monticello you wont find a label written "modern" on it. The label you may find on it is more like "abandonware". > > > > Also there like a ton of OOP languages out there using git with no major problems, the problem with smalltalk is that smalltalk is an island. > > > > And the problem with islands is when you end having fun with them you feel stuck since they dont provide an easy access to the outside world. > > > > "Git just manages blobs, text files at best. Dead text" > > > > Last time I checked Monticello used a format called mcz which is nothing more than a zip file containing st files, which are as you call it "dead text" files. Also I would like to remind you that git is used by the CUIS smalltalk to version control their images, I thought images are live code. > > > > Personally I dont see the diffirence between live and dead text. Its just text to me. The VM is the one that makes it live anyway. > > Yes and no. > > If git compares two versions, it does not understand what is in it. > > When Monticello compares versions, it knows about classes, methods, inheritance, > it can explain diffs in the same structured (browsable) form that you wrote them. > > Putting Smalltalk in plain text files can be done, has been done, and was not successful, because you lose something essential by leaving the environment. > > The island argument is also a bit too easy: any platform can be seen as an island that needs to integrate with others, there are degrees of openness. Your Blender or Python are islands too, just like SAP, Microsoft and Oracle. Some connections/interfaces are easy, some are hard(er). It all depends on your position. > > When have you last looked at the source code of git ? > > And be honest, do you find git always easy to use ? > > > On Tue, Jan 26, 2016 at 5:09 PM Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > > On 26 Jan 2016, at 15:59, Dimitris Chloupis <kilon.alios@gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > > > > > To be fair my experience with pharo and git have been not always smooth either. I have the VM crashing again and again completely randomly when it was trying to pull SmaCC as dependency for my project Ephestos, had to drop SmaCC and moving my python type parsing at python side. > > > > > > But I find it ironic someone using Monticello, trying to equate git with dark ages, you cant get more dark ages than monticello, frankly. No offense to people who made it , its great that is in there but its full of problems and bad designs and cant even begin to be compared with Github and GIT GUI clients. Monticello is according to my personal opinion by far the worst tool of Pharo. > > > > No it is not. It is a version management system that understands our object and code model, a system that we control. Git just manages blobs, text files at best. Dead text. > > > > (This does not mean it is perfect, nor that it cannot improve, nor that we should not improve our git integration.) > > > > > On Tue, Jan 26, 2016 at 4:51 PM Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2016-01-26 15:11 GMT+01:00 Sean P. DeNigris <sean@clipperadams.com <mailto:sean@clipperadams.com>>: > > > NorbertHartl wrote > > > > - I need to use BaselineOf instead of ConfigurationOf. Thus you cannot use > > > > Versionner anymore > > > > > > Unfortunately. This is the biggest drag for me after switching all my > > > personal projects to git (GitHub for public and BitBucket for private). I > > > had gotten spoiled by Versionner and hand-editing MetaC artifacts feels like > > > going back to the dark ages :/ > > > > > > Well, I guess copying the baselines generated by Versionner into a BaselineOf is probably a way to do it. > > > > > > Thierry > > > > > > > > > > > > > > > ----- > > > Cheers, > > > Sean > > > -- > > > View this message in context: http://forum.world.st/Pharo-git-workflow-tp4874067p4874221.html > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > >
Finally I got something working for me. It is not generally applicable but at the moment I'm happy this works at least. I made it even harder because I store the smalltalk code in a sub directory because I want to version web resources along with the code. The smalltalk code is in a sub directory st/ development desktop - - - - - - - - - - - - - - - - Normal GitFileTree workflow: - Take a pharo4 image and load the configuration of GitFileTree from the Configuration Browser. - Open Versionner then select GitFileTree and click on development and then load version (via context menu). This is IMHO only needed if you want to access bitbucket - Checkout your repository - Create GitFileTree repository and select directory of checked out repository - If a ssh key is configured in bitbucket and for the local ssh-agent commit, pull, push should work via monticello browser jenkins - - - - - In the jenkins build I like to avoid GitFileTree because I prefer having neither GitFileTree nor OSProcess installed in my deployment artefacts - Configure jenkins git plugin to check out the code repository - add a shell command consisting pharo-vm-nox project.image config "filetree://$WORKSPACE/st" ConfigurationOfProject --install=bleedingEdge - this has access to the ConfigurationOfProject but only to this class - Add spec repository: 'filetree://st/' to the baseline of the ConfigurationOfProject. This way metacello can load the rest of the packages. The good news is that I can have a full powered GitFileTree enabled version for developing and a OSProcess-less version for deployment. And I can use Versionner as I rely on the ConfigurationOf. But especially the spec repository setting in the ConfigurationOfProject is a bad hack. Another solution to this would be welcomed. This works only if all packages are in the same git repository. I need to try access that stuff via bitbucket:// url in the metacello baseline. Thierry just added support to put credentials in the url so it might work with downloading read-only versions of the repository. Norbert
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
thanks,
Norbert
Norbert, If you were using a BaselineOf for your project then you could avoid the the configuration hack by using the Metacello lock command[1] which was designed to address the problem where you want to use a local git clone while specifying project references in the configurations using the github (or bitbucket) repository url.... I understand that BaselineOf support is missing from versionner, but until the rest of the tool chain is in place, you will have to trade off where you want to "insert hacks" ... it may be easier to hand edit the BaselineOf when adding a new package or project dependency, than constantly hack configurations because you aren't using a BaselineOf --- but then that's up to you:) Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandRe... On 01/28/2016 09:39 AM, Norbert Hartl wrote:
Finally I got something working for me. It is not generally applicable but at the moment I'm happy this works at least. I made it even harder because I store the smalltalk code in a sub directory because I want to version web resources along with the code. The smalltalk code is in a sub directory st/
development desktop - - - - - - - - - - - - - - - -
Normal GitFileTree workflow:
- Take a pharo4 image and load the configuration of GitFileTree from the Configuration Browser. - Open Versionner then select GitFileTree and click on development and then load version (via context menu). This is IMHO only needed if you want to access bitbucket - Checkout your repository - Create GitFileTree repository and select directory of checked out repository - If a ssh key is configured in bitbucket and for the local ssh-agent commit, pull, push should work via monticello browser
jenkins - - - - -
In the jenkins build I like to avoid GitFileTree because I prefer having neither GitFileTree nor OSProcess installed in my deployment artefacts
- Configure jenkins git plugin to check out the code repository - add a shell command consisting
pharo-vm-nox project.image config "filetree://$WORKSPACE/st" ConfigurationOfProject --install=bleedingEdge
- this has access to the ConfigurationOfProject but only to this class - Add
spec repository: 'filetree://st/'
to the baseline of the ConfigurationOfProject. This way metacello can load the rest of the packages.
The good news is that I can have a full powered GitFileTree enabled version for developing and a OSProcess-less version for deployment. And I can use Versionner as I rely on the ConfigurationOf. But especially the spec repository setting in the ConfigurationOfProject is a bad hack. Another solution to this would be welcomed. This works only if all packages are in the same git repository. I need to try access that stuff via bitbucket:// url in the metacello baseline. Thierry just added support to put credentials in the url so it might work with downloading read-only versions of the repository.
Norbert
Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norbert@hartl.name>:
I'm eager to try a new project with some git repositories. But to be honest I don't really get it. Searching the web there is lots to find but nothing actual.
I don't understand if it is ok to use a ConfigurationOf or if it only works with a BaselineOf. And how do you specify the repository in a ConfigurationOf in order to be able to work locally as well as having jenkins pull everything automatically? Same goes for dependent projects.
Are there any insights to this or pointers to an up-to-date documentation?
thanks,
Norbert
participants (10)
-
Cyril Ferlicot D. -
Dale Henrichs -
Dimitris Chloupis -
Esteban Lorenzano -
Norbert Hartl -
Offray Vladimir Luna Cárdenas -
Sean P. DeNigris -
Serge Stinckwich -
Sven Van Caekenberghe -
Thierry Goubier