[Moose-dev] Re: About Famix-Core-GuillermoSchwarz.123

If you are working with Alex, I suggest that he shows you the basic tricks when working with Monticello. On 11 oct. 2010, at 18:43, Guillermo Schwarz wrote: > Hi Simon, > > Thanks for pointing this out. I understand most distributed version > control engines were all done in parallel, I'm still getting used to > Mercurial so whenever I find a difference I need to write it down > somewhere in order to remember. > > I'm glad that you replied. I think my commit is incomplete, but I didn't > know how to verify that. For some reason the Kernel project showed an > asterisk in Monticello, so I guessed that I modified something in the > Kernel project. It allowed me to check it in until the last moment when > it said "you are not authorized". Following GitHub rules it could allow > me fork the kernel project (clone) or allow me to send an email to the > Kernel project developers with my change (as suggested in the Cathedral > and the Bazaar). I don't know which would be best, but I guess "both" > would be the best answer. Did you read the stuff about Monticello in Pharo by Example? http://pharobyexample.org/ It might help you to get started. If you think you have changed something in Kernel, check "Changes" to see if it's really yours (sometimes a package such as Kernel appears dirty because of some automatic process) If you do have changes related to your fix in Kernel, then there is a good probability that such changes should be declared as class extensions from your package, not inside Kernel. Check again the Monticello section for how to do that. In most cases, you don't hack core packages such as Kernel unless you found a bug (then you should submit an issue to the Pharo project). You extend core packages with class extensions. > > The comment that you mentioned that I wrote is about how do I know the > history in Monticello? For example in Mercurial all the changes are > local and then you merge the changes locally by pulling from the remote > repository. While Mercurial is not ideal in the sense that having so > much dependencies can get confusing, the advantage is that when the > central repository goes down, you can easily setup a new repository > using a 3 day old copy and ask all committers to point to the new > central repository and reapply all their commits. It is so easy because > Mercurial calculates on the fly what it needs to push. > > Monticello on the other hand seems to allow to commit on a change by > change basis to wherever I want: A local file, any remote repository, > etc. And it is up to me to figure out (and remember) where I stored > what. I would be really hard for me to remind any of that. Yep that's the weak point in Monticello. Although normally, all your history should be in your local cache. So you can always copy from your local cache to another repo. Now it's a question of process. If possible, always commit to the same repository (like on squeaksource). If you are offline and commit only locally, then Gofer can help you to synchronize your local cache with your distant repo. The very basic things to understand with Monticello - a Monticello package is self-contained: you can always load it anywhere - however if you need to merge something, you need all packages in the ancestry so that Monticello can compute the differences with the common ancestor. > Since I was uploading 2 packages, what I would like is to have a package > dependency manager like Maven. Does that already exist or I would need > to recreate that from scratch? If your dependencies are basic and within the same repository, you can use the "required package" feature of Monticello. Otherwise, you will have to use Metacello. > > Regarding how to verify the commit I did, I would expect that there > would be a build machine. Since there seems to be no build machine, the > process recommended in Pharo by Example is to download the code from > Squeak Source into a clean image. Do I need to recreate the project in > Monticello and then download the code? Not sure I understand what you mean. There is an integration server for Moose. Now if your project is not part of Moose default, you have to check by yourself that it loads ok in a new image. http://hudson.moosetechnology.org/ > > Cheers, > Guillermo. > > On Mon, 2010-10-11 at 14:32 +0200, Simon Denier wrote: >> Hi Guillermo >> >> I saw your commit and especially your comment >> >> "saving locally first, then remotelly, doesn't simply copy the changes like Mercurial does..." >> >> The way it works with Monticello, compared to Git/Mercurial (remember that Monticello was conceived before/in parallel with such systems...) >> - the save command in MC always creates a new version of your package in the repository you selected >> - saving a version on a remote repository also saves a local copy >> - if you want to save a version first locally, then want to copy it later to another repository, use the "copy" command from the MC browser >> >> Alternatively, the Gofer API provides commands which are closes to Git/Mercurial workflows: push/fetch etc. >> See http://www.lukas-renggli.ch/blog/gofer >> >> >> BTW, is the fix complete? Your package only provides a new method FamixReference>>identityInstanceVariables >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simplex Veri Sigillum > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev