Loading Local Repositories with Iceberg
I'm using the Pharo 6.1 image with the Pharo Launcher. I have committed changes to several local github repos through Iceberg. I would like to be able to clone a new 6.1 image and load all the locally committed packages. I have "Share repositories between images" checked in both images, and the path looks right, but I do not see any of my repos in the fresh image. Is there something I need to do to load them? I tried "add local repository" but it claimed none of my repositories had any packages to load. I have had no trouble pushing to github and downloading my packages again from there on a different computer, but I am afraid to try it on the same computer in case the repositories collide. In short, what is the best way to set up the project I was working on in a fresh image so I can continue working on it? Thanks, Evan
Evan Donahue wrote
I have "Share repositories between images" checked in both images
What that option does is look in a standard shared location for the clone of a particular repo in the form {{shareRoot}}/{{username}}/{{repoName}} (e.g. ~/MySharedRoot/seandenigris/Magritte3) instead of making a fresh clone for each image (within the image folder by default). It does not automatically create domain objects for these clones in an image. Evan Donahue wrote
what is the best way to set up the project I was working on in a fresh image so I can continue working on it?
Probably by loading a BaselineOfYourProject via the Metacello scripting API. If you #enableMetacelloIntegration, this will add repos to Iceberg as necessary as your project is loaded. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time. Stephan
hi,
On 4 Jun 2018, at 12:57, Stephan Eggermont <stephan@stack.nl> wrote:
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time.
not really. P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit. Esteban
Stephan
P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
So are we saying that the easiest and less complicated option is to just have local copies for every project. These days, disk space is pretty cheap (and projects arenât that big source wise)? Iâm sure for others it might be a bigger deal - but Iâm trying to understand what is the easiest option to avoid gotchaâs (that more advanced guys can better cope with) Tim
On 4 Jun 2018, at 14:59, Esteban Lorenzano <estebanlm@gmail.com> wrote:
hi,
On 4 Jun 2018, at 12:57, Stephan Eggermont <stephan@stack.nl> wrote:
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time.
not really. P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
Esteban
Stephan
On 4 Jun 2018, at 18:59, Tim Mackinnon <tim@testit.works> wrote:
P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
So are we saying that the easiest and less complicated option is to just have local copies for every project. These days, disk space is pretty cheap (and projects arenât that big source wise)?
is about you :)
Iâm sure for others it might be a bigger deal - but Iâm trying to understand what is the easiest option to avoid gotchaâs (that more advanced guys can better cope with)
most of the time you do not switch all the time. most of the time you can work on a feature in image A that will detach image B. But then, most of the time you will want to update image B (or kept it detached, is your choice). cheers, Esteban
Tim
On 4 Jun 2018, at 14:59, Esteban Lorenzano <estebanlm@gmail.com> wrote:
hi,
On 4 Jun 2018, at 12:57, Stephan Eggermont <stephan@stack.nl> wrote:
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time.
not really. P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
Esteban
Stephan
On 5 June 2018 at 00:59, Tim Mackinnon <tim@testit.works> wrote:
P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
So are we saying that the easiest and less complicated option is to just have local copies for every project. These days, disk space is pretty cheap (and projects arenât that big source wise)?
For me its not the disk space, but the download time to sync the full Pharo repo if I want to work on an issue. I often wonder how hard it would be to have a master copy of the Pharo repo and each Image does something like --reference or --shared,, but I'm not familiar with their operation and issues except what I read here... * https://randyfay.com/content/reference-cache-repositories-speed-clones-git-c... * https://stackoverflow.com/questions/23304374/what-are-the-differences-betwee... * http://lists-archives.com/git/494327-clarify-git-clone-local-shared-referenc... * http://blog.plataformatec.com.br/2013/05/how-to-properly-mirror-a-git-reposi... cheers -ben
Iâm sure for others it might be a bigger deal - but Iâm trying to understand what is the easiest option to avoid gotchaâs (that more advanced guys can better cope with)
Tim
On 4 Jun 2018, at 14:59, Esteban Lorenzano <estebanlm@gmail.com> wrote:
hi,
On 4 Jun 2018, at 12:57, Stephan Eggermont <stephan@stack.nl> wrote:
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time.
not really. P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
Esteban
Stephan
Esteban Lorenzano <estebanlm@gmail.com> wrote: .
P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
Ah, nice. How is that guarded against concurrent access, live-lock & dead-lock? Stephan
but Iâm trying to understand what is the easiest option to avoid gotchaâs (that more advanced guys can better cope with)
I guess the question is whether you want to handle conflict resolutions directly with git, or through iceberg. I've been using separate clones for each image for a long time and it works well. Especially when you are also modifying non-smalltalk files in each clone. Peter On Mon, Jun 4, 2018 at 7:26 PM, Stephan Eggermont <stephan@stack.nl> wrote:
Esteban Lorenzano <estebanlm@gmail.com> wrote: .
P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
Ah, nice. How is that guarded against concurrent access, live-lock & dead-lock?
Stephan
Am 04.06.2018 um 19:26 schrieb Stephan Eggermont <stephan@stack.nl>:
Esteban Lorenzano <estebanlm@gmail.com> wrote: .
P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
Ah, nice. How is that guarded against concurrent access, live-lock & dead-lock?
Usually git supports that out of the box. I hope libgit does not do anything different.
Stephan
Norbert Hartl <norbert@hartl.name> wrote:
Am 04.06.2018 um 19:26 schrieb Stephan Eggermont <stephan@stack.nl>: Ah, nice. How is that guarded against concurrent access, live-lock & dead-lock?
Usually git supports that out of the box. I hope libgit does not do anything different.
https://danluu.com/file-consistency/ https://danluu.com/filesystem-errors/ And we have multiple libgit versions from the different vms accessing the same repo that need to work on a lot of different file systems Stephan
Am 05.06.2018 um 09:03 schrieb Stephan Eggermont <stephan@stack.nl>:
Norbert Hartl <norbert@hartl.name> wrote:
Am 04.06.2018 um 19:26 schrieb Stephan Eggermont <stephan@stack.nl>: Ah, nice. How is that guarded against concurrent access, live-lock & dead-lock?
Usually git supports that out of the box. I hope libgit does not do anything different.
https://danluu.com/file-consistency/ https://danluu.com/filesystem-errors/
And we have multiple libgit versions from the different vms accessing the same repo that need to work on a lot of different file systems
Ok, but where is the problem? Norbert
Am 05.06.2018 um 16:13 schrieb Stephan Eggermont <stephan@stack.nl>:
Norbert Hartl <norbert@hartl.name> wrote:
Ok, but where is the problem?
- needs to work on different filesystems, with tricky behavior - git itself did not get the behavior right - git used to be non-reentrant. Did that change?
Ok, now we know about problems git should solve. What should we be doing? Norbert
2018-06-05 16:24 GMT+02:00 Norbert Hartl <norbert@hartl.name>:
Am 05.06.2018 um 16:13 schrieb Stephan Eggermont <stephan@stack.nl>:
Norbert Hartl <norbert@hartl.name> wrote:
Ok, but where is the problem?
- needs to work on different filesystems, with tricky behavior - git itself did not get the behavior right - git used to be non-reentrant. Did that change?
Ok, now we know about problems git should solve. What should we be doing?
Avoid sharing a git repository between Pharo images / processes. Consider that git is a slightly unsafe way to store files in a single place; use git distributed nature (even in the same machine) as a way to cope with its limitations. Or switch to Fossil, whose use of sqlite seems safer from that viewpoint. Regards, Thierry
Norbert
Am 04.06.2018 um 15:59 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
hi,
On 4 Jun 2018, at 12:57, Stephan Eggermont <stephan@stack.nl> wrote:
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time.
not really. P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
How does this work if the other image has updated the git index? Repairing will update&merge, too? That is usually the reason I commit always first so I commit to a prior version of the index in order to have git merge on update. Norbert
Esteban
Stephan
On Tue, Jun 5, 2018 at 8:20 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 04.06.2018 um 15:59 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
hi,
On 4 Jun 2018, at 12:57, Stephan Eggermont <stephan@stack.nl> wrote:
Evan Donahue <emdonahu@gmail.com> wrote:
I have "Share repositories between images" checked in both images,
Share repositories at the moment just provides a shared location on disk where the repositories are located. That is only useful if you are very disciplined about stashing and switching to the branch needed for your current image, and you only have one image open at a time.
not really. P7 will force you to be in the right branch or you will not be able to do⦠almost anything :) you can have two (or ten) images opened at once and work on them, but at a moment you will need to ârepairâ each image to commit.
How does this work if the other image has updated the git index?
Iceberg ignores completely git's index (until the moment you commit). I cannot tell it 100% sure but It probably depends on the particular scenario you're on but IIRC: - if you checkout with iceberg, it will most surely discard your index; - if you try to commit with iceberg and you have a dirty index, iceberg will commit coming from your image along with the thing in the index
Repairing will update&merge, too?
What the merge operation does depends on the kind of merge: - a fast forward will just checkout the new commit in disk, probably discarding your index - a non fast forward will leave the disk as is, without touching the index (until you resolve the conflicts and then Iceberg will commit, which should do what I explained above)
That is usually the reason I commit always first so I commit to a prior version of the index in order to have git merge on update.
Yes, I'd recommend people to try to have a clean working copy when using iceberg, and specially a clean index.
Norbert
Esteban
Stephan
-- 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
participants (10)
-
Ben Coman -
Esteban Lorenzano -
Evan Donahue -
Guillermo Polito -
Norbert Hartl -
Peter Uhnák -
Sean P. DeNigris -
Stephan Eggermont -
Thierry Goubier -
Tim Mackinnon