2016-02-04 13:09 GMT+01:00 Henrik Johansen <henrik.s.johan...@veloxit.no>:
> > > On 04 Feb 2016, at 10:26 , Thierry Goubier <thierry.goub...@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 > Henry, you perfectly nailed it... Break it first/throw away/replace is not allways a winning strategy. We are ready to re-integrate source code in image at the price of a few MBytes, but it was urgent to throw history away BEFORE we even get a working replacement... Here is a mail i did not send because I didn't want to be to start the year too negativily: ---------------------------- "snip... was about a regexp bug that I tried to bisect... (a post of january 2015) So I wanted to be informed of the other changes going on since plenty of interesting things are going on in Pharo. Ah hem, but the package has been renamed and the 'version history' menu is there only to show me that history has been purposely expunged from image... It became such a useless menu now, that i think you could as well remove it. Spawning the 4.0 repository and using the History button, reveals a bit of history this time, sounds like the 3.0 bits... Notice in attachment how the versions 22 and 23 which are in the 3.0 repository seems to be missing... Ah, no this is a brand new strategy for presenting the merged branches... without any care for a common ancestor. Notice in other attachment how it's not allways been so. And what if I want to look a bit further behind? Shall I go outside the image and browse github now? The web UI did absolutely not work for me, the 3.0 history is cut there too, and blame only reveals me the name of Jenkins... Git command line might have done a better work, but anyway, doesn't the I in IDE stands for Integrated? I won't know because at this stage i gave up. snip... that's enough ranting "
