Iceberg Default Subdirectory Setting?
I always put my packages in gitroot/repository per instructions I read when I was starting with FT (Dale's IIRC). It's a (minor) drag to type that every time I add a local git repo. How would y'all feel about a setting? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 20/09/17 23:50, Sean P. DeNigris wrote:
I always put my packages in gitroot/repository per instructions I read when I was starting with FT (Dale's IIRC). It's a (minor) drag to type that every time I add a local git repo. How would y'all feel about a setting?
Is that shared with multiple images? How do you deal with needing different branches of the same repo? Stephan
Stephan Eggermont-3 wrote
Is that shared with multiple images?
There is already a setting to share repos (actually to set a default repo root folder). This setting would just be for where the packages live relative to the git root folder of that particular repo (e.g. ./src, ./repository, etc). Also, you'd still be able to alter it, I'm just talking about the default value in the "Add local repo" dialog. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 21-09-17 03:40, Sean P. DeNigris wrote:
Stephan Eggermont-3 wrote
Is that shared with multiple images?
There is already a setting to share repos (actually to set a default repo root folder). This setting would just be for where the packages live relative to the git root folder of that particular repo (e.g. ./src, ./repository, etc). Also, you'd still be able to alter it, I'm just talking about the default value in the "Add local repo" dialog.
I'm not quite sure how that share repos works. I normally have many images open that use different versions of shared repos. Git repos only have one current version. Stephan
Stephan Eggermont-3 wrote
I'm not quite sure how that share repos works.
My understanding is that it only works for certain straightforward workflows. Luckily, my guess is that many if not most users have such a workflow (e.g. single contributor/user projects where everything is committed to master) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 21-09-17 16:07, Sean P. DeNigris wrote:
Stephan Eggermont-3 wrote
I'm not quite sure how that share repos works.
My understanding is that it only works for certain straightforward workflows. Luckily, my guess is that many if not most users have such a workflow (e.g. single contributor/user projects where everything is committed to master)
The problem with that is that nearly none of the power users have such a workflow. That is what killed versionner. And also for single contributor you need to compare with old versions regularly Stephan
Stephan Eggermont-3 wrote
The problem with that is that nearly none of the power users have such a workflow.
I assume that's why it's a setting ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
I do not understand what is the problem. You have different approaches: 1) you work always on same branch (even if you âjumpâ from branchs): like today I work on âissue-1â and tomorrow on âissue-2â. You just switch branchs on your iceberg tool and thatâs all. 2) you work on different branchs at same time and you do not want to switch branches all the time. Then you just have two clones and points to this different clones. in general, Iâm working on different branches all the time (pharo branches, so big projects) and I prefer to use pattern (1), but you can also use pattern (2)⦠as I said⦠I do not understand what is the problem :) Esteban
On 21 Sep 2017, at 18:33, Sean P. DeNigris <sean@clipperadams.com> wrote:
Stephan Eggermont-3 wrote
The problem with that is that nearly none of the power users have such a workflow.
I assume that's why it's a setting ;)
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On 21-09-17 18:54, Esteban Lorenzano wrote:
I do not understand what is the problem. You have different approaches:
1) you work always on same branch (even if you âjumpâ from branchs): like today I work on âissue-1â and tomorrow on âissue-2â. You just switch branchs on your iceberg tool and thatâs all. 2) you work on different branchs at same time and you do not want to switch branches all the time. Then you just have two clones and points to this different clones.
in general, Iâm working on different branches all the time (pharo branches, so big projects) and I prefer to use pattern (1), but you can also use pattern (2)⦠as I said⦠I do not understand what is the problem :)
You cannot use pattern 2 with shared repos. Stephan
On 21 Sep 2017, at 20:08, stephan <stephan@stack.nl> wrote:
On 21-09-17 18:54, Esteban Lorenzano wrote:
I do not understand what is the problem. You have different approaches: 1) you work always on same branch (even if you âjumpâ from branchs): like today I work on âissue-1â and tomorrow on âissue-2â. You just switch branchs on your iceberg tool and thatâs all. 2) you work on different branchs at same time and you do not want to switch branches all the time. Then you just have two clones and points to this different clones. in general, Iâm working on different branches all the time (pharo branches, so big projects) and I prefer to use pattern (1), but you can also use pattern (2)⦠as I said⦠I do not understand what is the problem :)
You cannot use pattern 2 with shared repos.
yes you can. shared repo is a suggestion, you can always chose to add a project from another place. Esteban
Stephan
On 22 Sep 2017, at 09:20, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 21 Sep 2017, at 20:08, stephan <stephan@stack.nl> wrote:
On 21-09-17 18:54, Esteban Lorenzano wrote:
I do not understand what is the problem. You have different approaches: 1) you work always on same branch (even if you âjumpâ from branchs): like today I work on âissue-1â and tomorrow on âissue-2â. You just switch branchs on your iceberg tool and thatâs all. 2) you work on different branchs at same time and you do not want to switch branches all the time. Then you just have two clones and points to this different clones. in general, Iâm working on different branches all the time (pharo branches, so big projects) and I prefer to use pattern (1), but you can also use pattern (2)⦠as I said⦠I do not understand what is the problem :)
You cannot use pattern 2 with shared repos.
yes you can. shared repo is a suggestion, you can always chose to add a project from another place.
btw⦠- metacello #lock function should work to âlockâ projects to other directions than url in baseline. I just donât know exactly how it works since I never did it myself. - iceberg itself should not re-clone a project you already have in your registry. That means if you have project A who depends on project B, and you are working on a branch of B, if you load B first, iceberg will take that version instead the one declared in baseline (I made this at ESUG, because seaside development requires it). Esteban
Esteban
Stephan
On 22-09-17 09:25, Esteban Lorenzano wrote:
In response to my:
You cannot use pattern 2 with shared repos.
yes you can. shared repo is a suggestion, you can always chose to add a project from another place.
Yes, so that makes pattern 2 practically impossible? Where am I going wrong? I create an image with a certain repo, checkout a branch. 6 months later I reopen the image and need to bring it up to date. For that I need to look at a few other images, having different versions/branches. I then need to create as many clones of the repo as I have images I need to compare, open them, switch their repos to the right clone and switch to the right branch and version. Stephan
On 22 Sep 2017, at 10:01, stephan <stephan@stack.nl> wrote:
On 22-09-17 09:25, Esteban Lorenzano wrote:
In response to my:
You cannot use pattern 2 with shared repos.
yes you can. shared repo is a suggestion, you can always chose to add a project from another place.
Yes, so that makes pattern 2 practically impossible?
why? is perfectly possible.
Where am I going wrong? I create an image with a certain repo, checkout a branch. 6 months later I reopen the image and need to bring it up to date.
yes, then you fetch and update⦠again, whatâs the problem? there is something Iâm missing about your reasoning :(
For that I need to look at a few other images, having different versions/branches. I then need to create as many clones of the repo as I have images I need to compare, open them, switch their repos to the right clone and switch to the right branch and version.
why? you can compare branches inside same image⦠and even switch to them and reload. This will not work for pharo itself (because of initialisation order), but it will work on other projects. one thing I want to add is a âreload on baseline orderâ option on baseline plugin⦠so you can update your system following a baseline. Esteban
Stephan
participants (4)
-
Esteban Lorenzano -
Sean P. DeNigris -
stephan -
Stephan Eggermont