Hi Dale, On Tue, Feb 2, 2016 at 11:35 AM, Dale Henrichs < dale.henri...@gemtalksystems.com> wrote:
> > > On 01/29/2016 05:17 PM, Eliot Miranda wrote: > >> Hi David, >> >> On Jan 29, 2016, at 2:45 PM, David Allouche <da...@allouche.net> wrote: >>> >>> Thanks Dale for all the explanations. >>> >>> How Monticello and version control relate in the big picture is starting >>> to make sense for me. >>> >>> Now, I better understand why filetree ended up uses a file-per-method >>> format, even though that is relatively hostile to git user interfaces >>> optimised for other languages. There is really a need for a file-per-class >>> exchange format, because that would works a lot better with the existing >>> VCS ecosystem. >>> >> I agree so strongly. Class file outs which are eg sorted by selector >> make much more sense. They won't hit the file name length limit. They >> make it trivial to maintain method and class comment time stamps. They're >> easier to construct into snapshots because it's easier to decode the file >> name. >> >> And then it's easy to add files for package load/unload scripts and for >> the history. And then one is much more decoupled from the specific back >> end. It could be mercurial just as easily as git. >> >> I think more package-based user interfaces would indeed be a very good >>> idea, for browsing and for source code management. >>> >>> Stef, I have the impression you think that git is popular because it is >>> a new shiny toy. I disagree with this idea. Git is a typical >>> worse-is-better tool. It's good enough for most people, but it still has >>> many shortcomings. It is popular in spite of its shortcomings. It became >>> popular as destination for projects shifting from CVS and Subversion. So it >>> is unlikely to be displaced by a newer, incrementally shinier tools. >>> Anything that will displace it will have to provide an improvement of a >>> similar magnitude as the jump between centralised and distributed version >>> control. >>> >> This is a good analysis. What's valuable to the Pharo community is not >> displacing an already functional dvcs (Monticello) with an ill-suited one >> (git), but in being able to function in ecosystems like github where people >> can display their identity and where infrastructure for bug reports etc >> exist. >> >> Still, I think it's a good idea not to restrict high level models to what >>> git provides if that's a less than ideal fit to the image model. >>> >> Absolutely. Dale's talk of ditching Monticello metadata fills me with >> repulsion and makes me want to ask is he trying to sabotage or what? >> > Eliot, you can't be serious - accusing me of sabotage? Ah, well.... how > about you assume that I'm doing "or what":) > > The Monticello metadata in a git repository is redundant and leads to > unnecessary commit conflicts -- end of story .... > 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. 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 Despite the fact that the Monticello metadata is redundant, I have made > sure that the Monticello metadata was included in FileTree from the very > beginning for the very reason that I wanted developers to be able to try > out FileTree, git and github without having to burn any Monticello bridges > .... if they didn't like FileTree, git and github, then they would be able > to back out of their use of git without losing data ... > Then forgive me. I couldn't see the wood for the trees. When I read your talk of eliminating the conflicts from git commits due to the Monticello metadata I infer that you're eliminating the Monticello metadata. I'm not sure I understand the implications of this, but it seems to me that a natural consequence is that the Montivcello metadata is lost and at that point merges and the like become problematic. What am I missing? > > It seems entirely destructive. >> > It is not destructive ... > >> We have a functional package manager which currently supports interchange >> between Pharo, Squeak and Cuis, >> > and GemStone? > > I assume that you are talking about Monticello packages and Monticello > repositories ... or what? > Yes. > > I am really not trying to do anything but "invent the future" --- I am not > trying to destroy, I am trying to improve ... If you are not able to see > the shortcomings of Monticello repositories (Note that I am distinguishing > between Monticello packages and Monticello repositories --- FileTree uses > Monticello packages and replaces Monticello repositories with git) and > where git has advantages over Monticello repositories, then you should > continue to use Monticello repositories ... > But what does this imply to some package that starts off in a Monticello repository and then spends some time in gitland? Can I merge again? If I can I'm happy. If I can't, I feel sabotaged. > Personally I don't see Monticello repositories going away anytime soon and > expect to support Monticello repositories in GsDevKit_home, tODE, and > Metacello for the rest of my life:) Fine. Except merging is, IIUC, about method time stamps and ancestry. If that gets preserved then I'm happy. But for the life of me I haven't read an explanation that reassures me that these are being preserved. Do you see the roots of my fear? Dale > _,,,^..^,,,_ confused, Eliot
