I don't understand broken history either. Yes there can be .mcz name clashes but UUID history is stored together in metadata no? 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)
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). 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. 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? 2016-02-04 7:53 GMT+01:00 Thierry Goubier <[email protected]>: > Le 03/02/2016 23:58, Dale Henrichs a écrit : > >> >> >> On 02/03/2016 02:34 PM, Thierry Goubier wrote: >> >>> Le 03/02/2016 22:51, Eliot Miranda a écrit : >>> >>>> >>>> >>>> On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Hi Eliot, >>>> >>>> Le 02/02/2016 21:54, Eliot Miranda a écrit : >>>> .... >>>> >>>> >>>> No it's /not/ the end of the story. The essential part of the >>>> story is >>>> how Monticello remains compatible and interoperable between >>>> dialects. I >>>> haven't seen you account for how you maintain that >>>> compatibility. As >>>> far as I can tell, you propose replacing the Monticello metadata >>>> with >>>> that from git. How do I, as a Squeak user with Monticello, ever >>>> get to >>>> look at your package again? As I understand it, moving the >>>> metadata >>>> from Monticello commit time to git means that the metadata is >>>> in a >>>> format that git determines, not Monticello. >>>> >>>> >>>> Yes. See below why. >>>> >>>> So I don't understand how on the one hand you can say "The >>>> Monticello >>>> metadata in a git repository is redundant and leads to >>>> unnecessary >>>> commit conflicts -- end of story ....", which implies you >>>> want to >>>> eliminate the Monticello metadata, and on the other hand you say >>>> you're >>>> keeping the Monticello metadata. I'm hopelessly confused. How >>>> does the >>>> Monticello metadata get reconstituted if it's been thrown away? >>>> >>>> What happens to the metadata in the following workflow? >>>> >>>> load package P from Monticello repository R into an image >>>> change P, commit via git to local git repository G >>>> load P from G into an image >>>> store P to R via Monticello >>>> >>>> >>>> It's not a scenario I've specifically worked on, but all the tech is >>>> implemented / implementable to do that perfectly. >>>> >>>> The only thing that is problematic there is that the only safe >>>> history is the one generated from git... there are so many MC >>>> packages with broken history that, on mcz packages, you have to >>>> admit that it's not safe to base things on their history. >>>> >>>> >>>> I'm sorry but I don't accept that. In the Squeak trunk we have history >>>> in our mczs that is correct. Certainly in VMMaker.oscog I have history >>>> that goes back a long time. If bugs have broken history then efforts >>>> should be made to repair that history. But you can't just write off >>>> Monticello history like that. >>>> >>> >>> I don't. You presuppose. >>> >>> I write tools that work with Monticello repositories, not just yours. >>> I have to do with what is given to me. On a general level, as a mcz >>> user, I'll just have to consider that you are as susceptible to be >>> trusted as with any other mcz producer. This means not much... >>> >> >> ... And this is the reason why I am inclined to favor option 3, which >> records the package version history as it existed at the point it was >> copied into a git repo. When copied back out from the git universe, >> create a version history that starts with the original version history >> and generates a history of the package in git .... >> > > Which is not very difficult to do given how GitFileTree is implemented. > And I agree this may well be the way to go. But ... > > Correct or not, the Monticello version history should be preserved .... >> > > I wonder about that. The property of the Monticello version history is > that it has value when you can access the versions listed in it. If you mix > repositories like that, unless you maintain a link to the previous mcz > repository, pre-git versions can't be accessed. So, most of the time, what > we do with a project moved under git is to clone the previous repository, > not take just the current head. > > (you'll notice, by the way, that vcs usually work that way when moving > from, say, CVS to git - you move the entire repository, not just the latest > version). > > In short, the question would really be: > 1- should we invest into making that integration of past history a selling > point (but I foresee issues down the road; I've only described one so far, > and I have seen others) > or > 2- into making a better "clone" of a package history, timestamps and > everything when moving a complete repository to git? > > Honestly, I'd consider 1- to be the easiest to implement. 2- there is > already some code floating around. > > Thierry > >
