> On 04 Feb 2016, at 10:26 , Thierry Goubier <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
