> > [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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
