Hi Thierry, > Am 25.01.2016 um 21:36 schrieb Thierry Goubier <thierry.goub...@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.goub...@gmail.com <mailto:thierry.goub...@gmail.com>>: >>> >>> Hi Norbert, >>> >>> Le 25/01/2016 20:01, Norbert Hartl a écrit : >>>> >>>>> Am 25.01.2016 um 18:09 schrieb Norbert Hartl <norb...@hartl.name >>>>> <mailto:norb...@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
