On Thu, Aug 9, 2018 at 11:18 AM Norbert Hartl wrote:
>
>
> Am 08.08.2018 um 14:12 schrieb Herbert Vojčík :
>
>
>
> Damien Pollet wrote on 8. 8. 2018 13:53:
>
> First of all, quick stupid question: I'm currently loading my code with
> gitlocal://./src as the repository URL (my workflow starts in a
>
> [SNIP]
> I think I can see what is the rationale behind it but I’m not sure this
> can be the way to go:
>
> - I don’t think there can be a „standard way“ of defining source
> directory. And I don’t think that a tool should enforce this however. I
> keep frontend and backend code in some reposi
> Am 08.08.2018 um 14:12 schrieb Herbert Vojčík :
>
>
>
> Damien Pollet wrote on 8. 8. 2018 13:53:
>> First of all, quick stupid question: I'm currently loading my code with
>> gitlocal://./src as the repository URL (my workflow
>> starts in a terminal rather than in a Pharo image)
>> Shoul
Norbert Hartl wrote on 8. 8. 2018 10:27:
Am 07.08.2018 um 16:00 schrieb Guillermo Polito :
Hi,
I'll write down some of the reasons of the project's design, like that I can
afterwards copy paste it in the wiki :).
First, this design did not came up from an egg. We worked on it for about
Damien Pollet wrote on 8. 8. 2018 13:53:
First of all, quick stupid question: I'm currently loading my code with
gitlocal://./src as the repository URL (my workflow starts in a terminal
rather than in a Pharo image)
Should I just remove the /src part, now that my repo has the project
metadat
First of all, quick stupid question: I'm currently loading my code with
gitlocal://./src as the repository URL (my workflow starts in a terminal
rather than in a Pharo image)
Should I just remove the /src part, now that my repo has the project
metadata?
Also, are more features planned for the .pro
> Am 07.08.2018 um 16:00 schrieb Guillermo Polito :
>
> Hi,
>
> I'll write down some of the reasons of the project's design, like that I can
> afterwards copy paste it in the wiki :).
>
> First, this design did not came up from an egg. We worked on it for about two
> months. And it is thoug
Only adding a small detail, the Metacello expression is used to generate
the project that is offered.
Also I see it as the Detached head status for projects that are loaded
using Metacello. Maybe we should display the dirtiness in other way, but I
think that is not a problem.
It is normal that a p
Hi,
I'll write down some of the reasons of the project's design, like that I
can afterwards copy paste it in the wiki :).
First, this design did not came up from an egg. We worked on it for about
two months. And it is thought to be backwards compatible and manage lots of
metacello particularities
Forgot one thing.
I find the new project feature quite intrusive. It will add those file to all
repos unasked. So I have a lot of dirty projects I have no write access to. How
is this supposed to work. Isn’t it better to assume defaults and add an option
to add project files?
Norbert
> Am 07
Great, thanks!
I used 1.2.0 a few days ago and I had some problems:
- some repos like voyage had a .properties file in the repo with content „{}“.
This made the repo unusable. The only thing noticed is that in the repo view in
iceberg the packages were named Voyage-Core.package instead of Voyag
11 matches
Mail list logo
