> On 04 Feb 2016, at 10:26 , Thierry Goubier <thierry.goubier@gmail.com> wrote:
>
> Le 04/02/2016 10:04, Nicolas Cellier a ��crit :
>> I don't understand broken history either.
>> Yes there can be .mcz name clashes but UUID history is stored together
>> in metadata no?
>
> Yes.
>
>> If some tool only trust .mcz name without checking UUID, consider it's a
>> bug, and let's correct it (there is some in Monticello Configuration Map)
>
> Gofer. In fact, most of Monticello never checks the UUID, only dependencies do, but this looks like a deprecated feature given how often it is used.
>
>> Or is it the fact that some .mcz could be missing?
>> Consider this is a feature, MC tools are robust to missing .mcz (it's
>> just that you'll have to redo the merge if you lost a common ancestor).
>
> What? You really consider that a feature?
>
>> Or is it the fact that some repository might contain only a slice of
>> history?
>> This is another feature... You can view all the versions in a collection
>> of repositories without needing to replicate.
>
> Understandable in theory. Unworkable over time and change (repositories disappear and die, and this stops working)
>
>> You can replicate if you want but it's not mandatory and completely
>> orthogonal.
>> So yes, this information - the list or repositories you want to consider
>> - has to be stored separetely and this can sound quite unconventional.
>> But IMO, it's an important feature: it gives much resilience for a very
>> low investment.
>> And that also mean that you can hardly break things (have unconsistent
>> history).
>
>> Maybe when you say broken, you mean not 100% git compatible?
>
> No, what I say is true mcz inconsistent history (missing versions making merges very unreliable, basically).
>
> I describe a while ago a case where, thanks to mcz features, I couldn't merge a small change done to Roassal without generating a ton of conflicts. I moved the three needed mcz(s) to git (the change ancestor, the change, and the current head), did git merge and had no conflicts.
>
> If you consider those features, then I disagree.

Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*.
I don't think anyone looked into why it happened.

Cheers,
Henry

*http://forum.world.st/FogBugz-Case-Issue-12776-Tools-Cancelling-quot-Previous-Contents-quot-in-a-Workspace-clears-the-currs-td4753381.html