> Am 07.08.2018 um 16:00 schrieb Guillermo Polito <guillermopol...@gmail.com>:
>
> 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/source. What does it mean for users not using the „standard“ name?
- 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.
- 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.
Norbert
