[Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

Thierry Goubier thierry.goubier at gmail.com
Sun May 29 08:28:48 EDT 2016


Le 29/05/2016 14:04, Peter Uhnak a écrit :
> On Sun, May 29, 2016 at 11:21:21AM +0200, Thierry Goubier wrote:
>> Le 29/05/2016 11:15, Peter Uhnák a écrit :
>>>   > All this is so that my .5 would not conflict with someone else .5
>>>
>>> How is this a problem? Because it will be "Me.5" and "You.5", so there
>>> can't be any conflict.
>>
>> Me.5 and Me.5 are possible...
>>
>> Think of numbering your own stuff on two different branches.
>>
>> More, Metacello depends on Me.5 5 to be greater than You.5 5 for some of the
>> baselines / configurations to work properly :)
>
> Can't it use the ancestry to decide?

I suggested that to Dale... Disregard version numbers, only consider as 
newer if the other is in the ancestry chain.

Would also be a lot more precise, because we would then use the package 
version UID instead of the name.version number approximation which can 
leads to failures or loading the wrong package in some cases.

> Because my impression is from this that merges are naive, compared to
> git which actually checks the ancestry of both up the common endpoint
> and diffs based on that.

This does not describe the Monticello merges. Monticello merges do walk 
the ancestry chain to find a common ancestor and does a three way merge, 
as git does.

The problem is that the Monticello ancestry chain is often damaged for 
three reasons: removing part of it to reduce memory usage (Done for the 
Pharo3 release), removing all or part of it because your package 
ancestry chain is too long (I remember seeing some packages doing that 
on purpose?), the common ancestor doesn't exist anymore in the 
repositories visible to Monticello (long-lived packages that have moved 
between repositories, typically).

When Monticello sees a version in the history, it expects the full 
package to be available in the repositories; if this package is the 
common ancestor of the merge and can't be retrieved, then the merge will 
fail.

What GitFileTree/git does there is to ensure that if a version is in the 
ancestry, it can be retrieved. Git merge also use that property. Any 
GitFileTree-like layer would provide the same property (FossilFileTree, 
for example).

Note: in the git documentation, it is stated that git may create virtual 
ancestors in some cases, to simplify/reduce the merge work. In such 
cases, if set up, the gitfiletree merge driver will be called for all 
those merges (i.e. a single merge in git may trigger multiple merges).

Obvious, isn't it ;)

Thierry

> Peter
>
>>
>> Thierry
>>
>>>
>>> Peter
>>>
>>> On Sun, May 29, 2016 at 10:37 AM, Sven Van Caekenberghe <sven at stfx.eu
>>> <mailto:sven at stfx.eu>> wrote:
>>>
>>>
>>>      > On 29 May 2016, at 10:28, Holger Freyther <holger at freyther.de <mailto:holger at freyther.de>> wrote:
>>>      >
>>>      >
>>>      >> On 29 May 2016, at 09:58, Sven Van Caekenberghe <sven at stfx.eu <mailto:sven at stfx.eu>> wrote:
>>>      >>
>>>      >>
>>>      >>>
>>>      >>> For some reason the package manager is refreshing all packages. I don't know why it happens, and it's quite annoying (because it slows down commits), but it doesn't cause any actual problems, so don't worry about it too much.
>>>      >>
>>>      >> As I understand it, what happens is the following: before you commit to your MC repo, you have to find the next version number; a check is then done in all relevant repos; the cached content is not used, but an actual refresh is done. All this is so that my .5 would not conflict with someone else .5 - the chance that this happens is very small, and the check does not really prevent it.
>>>      >
>>>      > I assumed that but can it be limited to the Repositories that are associated with the package? I am afraid that next time I travel I can not commit to my local repository (and ofcourse the speed part). :)
>>>
>>>      We should go one step further: add an option to totally disable this
>>>      check to go outside the target repo, it makes little sense. But MC
>>>      is a complex beast ...
>>>
>>>       > holger
>>>
>>>
>>>
>>
>>
>
>





More information about the Pharo-users mailing list