Re: [Pharo-dev] New Iceberg Version 1.2.1

[Guillermo Polito]

>
> [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 repositories together so the source
> is in my case in backend/source. What does it mean for users not using the
> „standard“ name?
>

Well, I think the opposite. The tool should enforce some standard way, and
then, if you want to diverge from it you should specify it explicitly.


> - I don’t see why there needs to be a 1:1 relationship between a
> repository and working copy in pharo. It is like this at the moment already
> but the .project file manifests this. So it should not be supported to have
> more source dirs in one git repo? It might be not a good idea that the
> client has to write the source dir but it opens the possibility that there
> can be more than one.
>

Our solution doesn't close the door either. Actually, we were thinking on
having composite projects (a project with subprojects), which would support
your use case. We are aware we wanted this for Pharo so for example we can
split pharo itself in several smaller subprojects instead of having the
mess of ~500 packages we have today. However, we were not aware of any
project out there using such setup, and previous iceberg versions was maybe
supporting this just "by chance" and not by design. (Just imagine that
having in the same image two repositories with the same git repository
behind but different source directories could be a way, but it's more of a
workaround).

This said, could you explain better how you were using this so far?
 - you have different source directories for frontend/backend?
 - you interact with them as different repositories in the same image? or
from different images pointing to the same repo?
 - every time you commit in one of the iceberg repositories you get
detached in the other(s)?

This said, I'd like to support this scenarios, but I want to do it by
design :)


> - My mode of working is to have an eye on dirty repositories because that
> shows what the impact of your work is. If I have a lot of dirty
> repositories in my repository list it does not feel good and I don’t want
> that. Especially for projects I don’t have write access to. How can I
> change this? I’m not sure that assuming everyone will add these files is a
> likely one.
>

Maybe we need to be less invasive with colors? My point of view is that
Monticello shows tons of packages and repositories, automatic rewrite and
auto-deprecation rules rewrite code dynamically and mark monticello
packages as dirty. But nobody ever complained about monticello or tried to
change it.

What are the packages you depend on and you have no write access to? If we
make a pull request per day, I think we can solve this situation really
fast...


>
> Norbert
>
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Damien Pollet]

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 .project file? E.g. what about
storing a default selection for Calypso and the Test Runner in there?

On Wed, 8 Aug 2018 at 10:28, Norbert Hartl  wrote:

> - 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 repositories together so the source
> is in my case in backend/source. What does it mean for users not using the
> „standard“ name?
>

Sure there can. Look at any ruby or maven project, they all have strong
conventions for organizing projects and standard config files for deviating
from those conventions.
I would have preferred if Iceberg picked one convention (arbitrarily) in
the absence of a .project file instead of forcing its explicit presence.
IMHO the choice of default directory per se (be it ./, ./src, ./source or
whatever) matters less than the fact that there is a convention in place.


> - I don’t see why there needs to be a 1:1 relationship between a
> repository and working copy in pharo. It is like this at the moment already
> but the .project file manifests this. So it should not be supported to have
> more source dirs in one git repo? It might be not a good idea that the
> client has to write the source dir but it opens the possibility that there
> can be more than one.
>

I see your point here, but by using separate source directories you're sort
of creating a hydra project… What I mean here is that the source
directories are separate, but their histories are tangled. If you want
separate source dirs it kinda means that you want separate change
histories, doesn't it? What if the same class has diverging definitions in
separate directories (I wonder what maven does in that case…)?

On the other hand, separate source directories would be helpful to work
with git-subrepo and similar tools…

-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Norbert Hartl]

> 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 thought to be backwards compatible and manage lots of 
> metacello particularities. It may have things that are perfectible, sure, so 
> let's discuss it.
> 
> One of the main problems we saw in metacello, and that Iceberg inherited, was 
> the "source subdirectory" thing. This source directory had to be specified in 
> the CLIENT, meaning that every time we clone a repository we should know by 
> heart the directory chose by its developer. Moreover, we lack a standard way 
> to do it, so everybody does as he feels (root directory, src, source, 
> repository, mc).
> 
> This has some bad consequences:
>  - once a repository is referenced by some other project, it is more 
> complicated to change its source directory. Imagine that tomorrow we set as 
> standard that all git repos should have the code in src. Then voyage should 
> change. And all its clients too.
>  - Making a typo in the code subdirectory means sometimes super ugly errors 
> from metacello that are difficult to debug and understand (e.g., "Cannot 
> resolve BaselineOfMetacello WTF")
> 
> Moreover, there was another problem that people started stumbling on: the 
> fact that iceberg got confused sometimes thinking that an empty project was 
> in filetree (to keep backwards compatibility with projects without a 
> .properties).
> 
> So we decided that for this release we wanted to revert a bit that situation. 
> Think object: let's put the meta-data used to interpret a project's structure 
> inside the project itself.
> The idea is that:
> 
>  - each project should contain both a .project and a .properties file. The 
> first can contain arbitrary project meta-data (such as the source directory). 
> The second contains the cypress properties, which are needed to correctly 
> interpret the code inside the source directory.
>  - a project without a .project file is an old project and cannot be 
> interpreted, because we don't know the source directory
>  - a project without a .properties file is an old project and is by default 
> transformed in a project with a #filetree properties file
>  - an old project cloned from iceberg detects the missing .project file and 
> gives the user the opportunity to declare it (and then commit it explicitly)
>  - an old project cloned and loaded from a Metacello expression defining a 
> source directory will honnor the source directory defined in the Metacello 
> expression (for backwards compatibility, and we have ~500 tests about this).
> 
> # About defaults values / forcing the user to define a project
> 
> First, notice that even when the repositories you load are just marked as 
> "dirty".
> This is because in memory we add a project to your repository.
> But you're not forced to commit it.
> Actually, you can still load packages and baselines from that repository 
> without committing.
> 
> This is in line with Iceberg's "explicitness". We try to not do any 
> destructive operation without asking the user first (that's why we have 
> several preview windows for pushing, pulling, checkout, merge..., and why 
> contrastingly with monticello we show the committed changes on the commit 
> window...). So, instead of transparently "adding the file" we have decided to 
> modify the project in memory and let the user the responsibility to commit 
> that file.
> 
> If there's a drawback, is that the repository is marked as dirty. Which is a 
> bit noisy, yes, but still I think it's not so bad compared with the previous 
> drawbacks.
> To solve this, we could have some default values, yes, and only mark it as 
> dirty if the project does not follow the default value.
> This could work, but right now all projects use different names for their 
> source directories.
> So the question is, what would be a good default? I'd like to use 'src' since 
> this is short, well known and less alien (all these in the sense that we do 
> not lose anything and we have a lot to gain by using it).
> However, not much repositories use 'src' so it will still produce a lot of 
> "noise"...
> 
> But still! Committing that file is a one-time operation. Once people fix 
> their repositories adding the project meta-data, you will not see them dirty 
> anymore. So we can see this as a transition noise too...
> 
> Of course, new ideas are welcome. I'll let Pablo and Esteban add their points 
> of view on this too.
> 
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 repositories together so the source is in my case in 
backend/sour

Re: [Pharo-dev] New Iceberg Version 1.2.1

[teso...@gmail.com]

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 project is marked dirty while used.

Cheers

On Tue, Aug 7, 2018 at 4:01 PM Guillermo Polito 
wrote:

> 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. It may have things that are perfectible, sure,
> so let's discuss it.
>
> One of the main problems we saw in metacello, and that Iceberg inherited,
> was the "source subdirectory" thing. This source directory had to be
> specified in the CLIENT, meaning that every time we clone a repository we
> should know by heart the directory chose by its developer. Moreover, we
> lack a standard way to do it, so everybody does as he feels (root
> directory, src, source, repository, mc).
>
> This has some bad consequences:
>  - once a repository is referenced by some other project, it is more
> complicated to change its source directory. Imagine that tomorrow we set as
> standard that all git repos should have the code in src. Then voyage should
> change. And all its clients too.
>  - Making a typo in the code subdirectory means sometimes super ugly
> errors from metacello that are difficult to debug and understand (e.g.,
> "Cannot resolve BaselineOfMetacello WTF")
>
> Moreover, there was another problem that people started stumbling on: the
> fact that iceberg got confused sometimes thinking that an empty project was
> in filetree (to keep backwards compatibility with projects without a
> .properties).
>
> So we decided that for this release we wanted to revert a bit that
> situation. Think object: let's put the meta-data used to interpret a
> project's structure inside the project itself.
> The idea is that:
>
>  - each project should contain both a .project and a .properties file. The
> first can contain arbitrary project meta-data (such as the source
> directory). The second contains the cypress properties, which are needed to
> correctly interpret the code inside the source directory.
>  - a project without a .project file is an old project and cannot be
> interpreted, because we don't know the source directory
>  - a project without a .properties file is an old project and is by
> default transformed in a project with a #filetree properties file
>  - an old project cloned from iceberg detects the missing .project file
> and gives the user the opportunity to declare it (and then commit it
> explicitly)
>  - an old project cloned and loaded from a Metacello expression defining a
> source directory will honnor the source directory defined in the Metacello
> expression (for backwards compatibility, and we have ~500 tests about this).
>
> # About defaults values / forcing the user to define a project
>
> First, notice that even when the repositories you load are just marked as
> "dirty".
> This is because in memory we add a project to your repository.
> But you're not forced to commit it.
> Actually, you can still load packages and baselines from that repository
> without committing.
>
> This is in line with Iceberg's "explicitness". We try to not do any
> destructive operation without asking the user first (that's why we have
> several preview windows for pushing, pulling, checkout, merge..., and why
> contrastingly with monticello we show the committed changes on the commit
> window...). So, instead of transparently "adding the file" we have decided
> to modify the project in memory and let the user the responsibility to
> commit that file.
>
> If there's a drawback, is that the repository is marked as dirty. Which is
> a bit noisy, yes, but still I think it's not so bad compared with the
> previous drawbacks.
> To solve this, we could have some default values, yes, and only mark it as
> dirty if the project does not follow the default value.
> This could work, but right now all projects use different names for their
> source directories.
> So the question is, what would be a good default? I'd like to use 'src'
> since this is short, well known and less alien (all these in the sense that
> we do not lose anything and we have a lot to gain by using it).
> However, not much repositories use 'src' so it will still produce a lot of
> "noise"...
>
> But still! Committing that file is a one-time operation. Once people fix
> their repositories adding the project meta-data, you will not see them
> dirty anymore. So we can see this as a transition noise too...
>
> Of course, new ideas are welcome. I'll let Pablo and Esteban add their
> points of view on this too.
> Guille
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] New Iceberg Version 1.2.1

[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 thought to be backwards compatible and manage lots of
metacello particularities. It may have things that are perfectible, sure,
so let's discuss it.

One of the main problems we saw in metacello, and that Iceberg inherited,
was the "source subdirectory" thing. This source directory had to be
specified in the CLIENT, meaning that every time we clone a repository we
should know by heart the directory chose by its developer. Moreover, we
lack a standard way to do it, so everybody does as he feels (root
directory, src, source, repository, mc).

This has some bad consequences:
 - once a repository is referenced by some other project, it is more
complicated to change its source directory. Imagine that tomorrow we set as
standard that all git repos should have the code in src. Then voyage should
change. And all its clients too.
 - Making a typo in the code subdirectory means sometimes super ugly errors
from metacello that are difficult to debug and understand (e.g., "Cannot
resolve BaselineOfMetacello WTF")

Moreover, there was another problem that people started stumbling on: the
fact that iceberg got confused sometimes thinking that an empty project was
in filetree (to keep backwards compatibility with projects without a
.properties).

So we decided that for this release we wanted to revert a bit that
situation. Think object: let's put the meta-data used to interpret a
project's structure inside the project itself.
The idea is that:

 - each project should contain both a .project and a .properties file. The
first can contain arbitrary project meta-data (such as the source
directory). The second contains the cypress properties, which are needed to
correctly interpret the code inside the source directory.
 - a project without a .project file is an old project and cannot be
interpreted, because we don't know the source directory
 - a project without a .properties file is an old project and is by default
transformed in a project with a #filetree properties file
 - an old project cloned from iceberg detects the missing .project file and
gives the user the opportunity to declare it (and then commit it explicitly)
 - an old project cloned and loaded from a Metacello expression defining a
source directory will honnor the source directory defined in the Metacello
expression (for backwards compatibility, and we have ~500 tests about this).

# About defaults values / forcing the user to define a project

First, notice that even when the repositories you load are just marked as
"dirty".
This is because in memory we add a project to your repository.
But you're not forced to commit it.
Actually, you can still load packages and baselines from that repository
without committing.

This is in line with Iceberg's "explicitness". We try to not do any
destructive operation without asking the user first (that's why we have
several preview windows for pushing, pulling, checkout, merge..., and why
contrastingly with monticello we show the committed changes on the commit
window...). So, instead of transparently "adding the file" we have decided
to modify the project in memory and let the user the responsibility to
commit that file.

If there's a drawback, is that the repository is marked as dirty. Which is
a bit noisy, yes, but still I think it's not so bad compared with the
previous drawbacks.
To solve this, we could have some default values, yes, and only mark it as
dirty if the project does not follow the default value.
This could work, but right now all projects use different names for their
source directories.
So the question is, what would be a good default? I'd like to use 'src'
since this is short, well known and less alien (all these in the sense that
we do not lose anything and we have a lot to gain by using it).
However, not much repositories use 'src' so it will still produce a lot of
"noise"...

But still! Committing that file is a one-time operation. Once people fix
their repositories adding the project meta-data, you will not see them
dirty anymore. So we can see this as a transition noise too...

Of course, new ideas are welcome. I'll let Pablo and Esteban add their
points of view on this too.
Guille

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Norbert Hartl]

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.08.2018 um 12:05 schrieb teso...@gmail.com:
> 
> New Iceberg Version 1.2.1 
> [https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 
>  + 
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1 
> ]
> Thanks to all brave users, issue reporters, and contributors :).
> 
> This version includes the implementation of projects. 
> Projects are a way of defining basic metadata of the repository.
> Now, this metadata just includes the source directory.
> 
> This means that people do not need anymore to provide ALL THE TIME the source 
> directory.
> Instead, every repository includes a project file that provides it.
> Iceberg will guide people to create the given file. This file is managed by 
> Iceberg and people should not touch it from the outside or accept the 
> consequences :).
> 
> This version is integrated in the latest Pharo 7 images.
> 
> #New Features
> 
>  - #866 Introduce first version of Projects 
> 
> #Infrastructure
> 
>  - #870 Improving tests of Metacello Integration
>  - #903 Split basic tests from metacello tests in CI
>  - #914 Sync Wiki with documentation directory automatically
>  - #934 Manually check metacello integration dialogs
>  - #935 Try to refrite the metacello integration tests.
>  - #940 Installation in new Pharo should also bootstrap pharo repository
> 
> #Enhancements
> 
>  - #675 The History of a Method in Calypso should show a progress bar. 
>  - #788 Show progress during network operations (fetch,push, ...) Libgit.
>  - #875 Tonel plugin does not delete .filetree Migration 
>  - #897 Update to OSSubprocess 1.0.1
>  - #911 Repair Checkout branch should appear in "no project found"
>  - #933 Fix Edit repository dialog
>  - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor
>  - #944 Extract pharo repository bootstrap code into iceberg 
> 
> #Bug Fixes
> 
>  - #828 Convert sources to tonel raises an Exception
>  - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong
>  - #849 VM crash while saving credentials Credential Manager
>  - #851 .properties file is not create if project is imported and not cloned.
>  - #869 Error msg after an http timeout is unreadable
>  - #873 Error with credential provider Credential Manager
>  - #874 The integration with Metacello does not work when there is a src 
> directory, but not project file.
>  - #880 Putting "." in project src field gives dnu
>  - #884 Edit Project Dialog tries to select 'src' folder as default, but does 
> not handle if it does not exists
>  - #886 Edit Project Dialog does not allow to select the root of the 
> repository as source directory
>  - #888 Could not locate repository does not have subdirectory anymore.
>  - #889 Loading an unborn project through metacello does not work
>  - #894 GitHubAPI fails when the API responds with a 204 No Content
>  - #901 I get a DNU projectName
>  - #902 Edit project metadata does not detect default format
>  - #918 Cloning pharo from a sync'ed repository does not correctly show dirty 
> packages 
>  - #928 Pull request cancel
>  - #930 Changed ivar/slot name in stateful trait not recognized as a change 
>  - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg 
> has been removed
>  - #932 Pharo repository forgets packages
>  - #938 Do not catch assertion failures
>  - #941 Iceberg pre-installed repository has wrong repair action
>  - #946 Fixing Metacello Integration Tests
>  - #948 Cloning from github creates an invalid remote
>  - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug
>  - #951 New project window should be coherent on the vocabulary UI enhancement
>  - #953 Make remote request anonymous enhancement
>  - #952 Cannot Clone Pharo Repository Pharo plugin bug
>  - #955 Repair actions for repositories with fetch required are wrong UI bug
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com 

Re: [Pharo-dev] New Iceberg Version 1.2.1

[Norbert Hartl]

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 Voyage-Core
- I had a problem that I cherry picked changes in my project and commited but 
then all other changes were gone, too. I need to revert and then reapply the 
changes with epicea in order to have it in iceberg. It can be it was influenced 
by the above problem but I need to check again which I will.

Norbert
  

> Am 07.08.2018 um 12:05 schrieb teso...@gmail.com:
> 
> New Iceberg Version 1.2.1 
> [https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 
>  + 
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1 
> ]
> Thanks to all brave users, issue reporters, and contributors :).
> 
> This version includes the implementation of projects. 
> Projects are a way of defining basic metadata of the repository.
> Now, this metadata just includes the source directory.
> 
> This means that people do not need anymore to provide ALL THE TIME the source 
> directory.
> Instead, every repository includes a project file that provides it.
> Iceberg will guide people to create the given file. This file is managed by 
> Iceberg and people should not touch it from the outside or accept the 
> consequences :).
> 
> This version is integrated in the latest Pharo 7 images.
> 
> #New Features
> 
>  - #866 Introduce first version of Projects 
> 
> #Infrastructure
> 
>  - #870 Improving tests of Metacello Integration
>  - #903 Split basic tests from metacello tests in CI
>  - #914 Sync Wiki with documentation directory automatically
>  - #934 Manually check metacello integration dialogs
>  - #935 Try to refrite the metacello integration tests.
>  - #940 Installation in new Pharo should also bootstrap pharo repository
> 
> #Enhancements
> 
>  - #675 The History of a Method in Calypso should show a progress bar. 
>  - #788 Show progress during network operations (fetch,push, ...) Libgit.
>  - #875 Tonel plugin does not delete .filetree Migration 
>  - #897 Update to OSSubprocess 1.0.1
>  - #911 Repair Checkout branch should appear in "no project found"
>  - #933 Fix Edit repository dialog
>  - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor
>  - #944 Extract pharo repository bootstrap code into iceberg 
> 
> #Bug Fixes
> 
>  - #828 Convert sources to tonel raises an Exception
>  - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong
>  - #849 VM crash while saving credentials Credential Manager
>  - #851 .properties file is not create if project is imported and not cloned.
>  - #869 Error msg after an http timeout is unreadable
>  - #873 Error with credential provider Credential Manager
>  - #874 The integration with Metacello does not work when there is a src 
> directory, but not project file.
>  - #880 Putting "." in project src field gives dnu
>  - #884 Edit Project Dialog tries to select 'src' folder as default, but does 
> not handle if it does not exists
>  - #886 Edit Project Dialog does not allow to select the root of the 
> repository as source directory
>  - #888 Could not locate repository does not have subdirectory anymore.
>  - #889 Loading an unborn project through metacello does not work
>  - #894 GitHubAPI fails when the API responds with a 204 No Content
>  - #901 I get a DNU projectName
>  - #902 Edit project metadata does not detect default format
>  - #918 Cloning pharo from a sync'ed repository does not correctly show dirty 
> packages 
>  - #928 Pull request cancel
>  - #930 Changed ivar/slot name in stateful trait not recognized as a change 
>  - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg 
> has been removed
>  - #932 Pharo repository forgets packages
>  - #938 Do not catch assertion failures
>  - #941 Iceberg pre-installed repository has wrong repair action
>  - #946 Fixing Metacello Integration Tests
>  - #948 Cloning from github creates an invalid remote
>  - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug
>  - #951 New project window should be coherent on the vocabulary UI enhancement
>  - #953 Make remote request anonymous enhancement
>  - #952 Cannot Clone Pharo Repository Pharo plugin bug
>  - #955 Repair actions for repositories with fetch required are wrong UI bug
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com 

[Pharo-dev] New Iceberg Version 1.2.1

[teso...@gmail.com]

New Iceberg Version 1.2.1 [
https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 +
https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1]
Thanks to all brave users, issue reporters, and contributors :).

This version includes the implementation of projects.
Projects are a way of defining basic metadata of the repository.
Now, this metadata just includes the source directory.

This means that people do not need anymore to provide ALL THE TIME the
source directory.
Instead, every repository includes a project file that provides it.
Iceberg will guide people to create the given file. This file is managed by
Iceberg and people should not touch it from the outside or accept the
consequences :).

This version is integrated in the latest Pharo 7 images.

#New Features

 - #866 Introduce first version of Projects

#Infrastructure

 - #870 Improving tests of Metacello Integration
 - #903 Split basic tests from metacello tests in CI
 - #914 Sync Wiki with documentation directory automatically
 - #934 Manually check metacello integration dialogs
 - #935 Try to refrite the metacello integration tests.
 - #940 Installation in new Pharo should also bootstrap pharo repository

#Enhancements

 - #675 The History of a Method in Calypso should show a progress bar.
 - #788 Show progress during network operations (fetch,push, ...) Libgit.
 - #875 Tonel plugin does not delete .filetree Migration
 - #897 Update to OSSubprocess 1.0.1
 - #911 Repair Checkout branch should appear in "no project found"
 - #933 Fix Edit repository dialog
 - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor
 - #944 Extract pharo repository bootstrap code into iceberg

#Bug Fixes

 - #828 Convert sources to tonel raises an Exception
 - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong
 - #849 VM crash while saving credentials Credential Manager
 - #851 .properties file is not create if project is imported and not
cloned.
 - #869 Error msg after an http timeout is unreadable
 - #873 Error with credential provider Credential Manager
 - #874 The integration with Metacello does not work when there is a src
directory, but not project file.
 - #880 Putting "." in project src field gives dnu
 - #884 Edit Project Dialog tries to select 'src' folder as default, but
does not handle if it does not exists
 - #886 Edit Project Dialog does not allow to select the root of the
repository as source directory
 - #888 Could not locate repository does not have subdirectory anymore.
 - #889 Loading an unborn project through metacello does not work
 - #894 GitHubAPI fails when the API responds with a 204 No Content
 - #901 I get a DNU projectName
 - #902 Edit project metadata does not detect default format
 - #918 Cloning pharo from a sync'ed repository does not correctly show
dirty packages
 - #928 Pull request cancel
 - #930 Changed ivar/slot name in stateful trait not recognized as a change
 - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg
has been removed
 - #932 Pharo repository forgets packages
 - #938 Do not catch assertion failures
 - #941 Iceberg pre-installed repository has wrong repair action
 - #946 Fixing Metacello Integration Tests
 - #948 Cloning from github creates an invalid remote
 - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug
 - #951 New project window should be coherent on the vocabulary UI
enhancement
 - #953 Make remote request anonymous enhancement
 - #952 Cannot Clone Pharo Repository Pharo plugin bug
 - #955 Repair actions for repositories with fetch required are wrong UI bug

-- 
Pablo Tesone.
teso...@gmail.com