Smalltalk › Pharo › Pharo Smalltalk Users

Loading Local Repositories with Iceberg

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Evan Donahue

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

Sean P. DeNigris

Re: Loading Local Repositories with Iceberg

Administrator

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

Cheers,
Sean

Stephan Eggermont-3

Re: Loading Local Repositories with Iceberg

In reply to this post by Evan Donahue

Evan Donahue <[hidden email]> 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

EstebanLM

Re: Loading Local Repositories with Iceberg

hi,

> On 4 Jun 2018, at 12:57, Stephan Eggermont <[hidden email]> wrote:
>
> Evan Donahue <[hidden email]> 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
>
>
>
>
>

Tim Mackinnon

Re: Loading Local Repositories with Iceberg

> 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 <[hidden email]> wrote:
>
> hi,
>
>> On 4 Jun 2018, at 12:57, Stephan Eggermont <[hidden email]> wrote:
>>
>> Evan Donahue <[hidden email]> 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
>>
>>
>>
>>
>>
>
>

Stephan Eggermont-3

Re: Loading Local Repositories with Iceberg

In reply to this post by EstebanLM

Esteban Lorenzano <[hidden email]>
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

Peter Uhnak

Re: Loading Local Repositories with Iceberg

> 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 <[hidden email]> wrote:

Esteban Lorenzano <[hidden email]>
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

EstebanLM

Re: Loading Local Repositories with Iceberg

In reply to this post by Tim Mackinnon

> On 4 Jun 2018, at 18:59, Tim Mackinnon <[hidden email]> 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 <[hidden email]> wrote:
>>
>> hi,
>>
>>> On 4 Jun 2018, at 12:57, Stephan Eggermont <[hidden email]> wrote:
>>>
>>> Evan Donahue <[hidden email]> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

Ben Coman

Re: Loading Local Repositories with Iceberg

In reply to this post by Tim Mackinnon

On 5 June 2018 at 00:59, Tim Mackinnon <[hidden email]> 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-clone-reference

* https://stackoverflow.com/questions/23304374/what-are-the-differences-between-git-clone-shared-and-reference

* http://lists-archives.com/git/494327-clarify-git-clone-local-shared-reference.html

* http://blog.plataformatec.com.br/2013/05/how-to-properly-mirror-a-git-repository/

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 <[hidden email]> wrote:
>
> hi,
>
>> On 4 Jun 2018, at 12:57, Stephan Eggermont <[hidden email]> wrote:
>>
>> Evan Donahue <[hidden email]> 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
>>
>>
>>
>>
>>
>
>

NorbertHartl

Re: Loading Local Repositories with Iceberg

In reply to this post by Stephan Eggermont-3

> Am 04.06.2018 um 19:26 schrieb Stephan Eggermont <[hidden email]>:
>
> Esteban Lorenzano <[hidden email]>
> 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
>
>
>

NorbertHartl

Re: Loading Local Repositories with Iceberg

In reply to this post by EstebanLM

> Am 04.06.2018 um 15:59 schrieb Esteban Lorenzano <[hidden email]>:
>
> hi,
>
>> On 4 Jun 2018, at 12:57, Stephan Eggermont <[hidden email]> wrote:
>>
>> Evan Donahue <[hidden email]> 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
>>
>>
>>
>>
>>
>
>

Stephan Eggermont-3

Re: Loading Local Repositories with Iceberg

In reply to this post by NorbertHartl

Norbert Hartl <[hidden email]> wrote:
>> Am 04.06.2018 um 19:26 schrieb Stephan Eggermont <[hidden email]>:
>> 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

NorbertHartl

Re: Loading Local Repositories with Iceberg

> Am 05.06.2018 um 09:03 schrieb Stephan Eggermont <[hidden email]>:
>
> Norbert Hartl <[hidden email]> wrote:
>>> Am 04.06.2018 um 19:26 schrieb Stephan Eggermont <[hidden email]>:
>>> 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

Guillermo Polito

Re: Loading Local Repositories with Iceberg

In reply to this post by NorbertHartl

On Tue, Jun 5, 2018 at 8:20 AM, Norbert Hartl <[hidden email]> wrote:

> Am 04.06.2018 um 15:59 schrieb Esteban Lorenzano <[hidden email]>:
>
> hi,
>
>> On 4 Jun 2018, at 12:57, Stephan Eggermont <[hidden email]> wrote:
>>
>> Evan Donahue <[hidden email]> 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

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Stephan Eggermont-3

Re: Loading Local Repositories with Iceberg

In reply to this post by NorbertHartl

Norbert Hartl <[hidden email]> 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?

Stephan

NorbertHartl

Re: Loading Local Repositories with Iceberg

> Am 05.06.2018 um 16:13 schrieb Stephan Eggermont <[hidden email]>:
>
> Norbert Hartl <[hidden email]> 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

Thierry Goubier

Re: Loading Local Repositories with Iceberg

2018-06-05 16:24 GMT+02:00 Norbert Hartl <[hidden email]>:

>
>
>> Am 05.06.2018 um 16:13 schrieb Stephan Eggermont <[hidden email]>:
>>
>> Norbert Hartl <[hidden email]> 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
>
>