New subject: About Famix-Core-GuillermoSchwarz.123

12 Oct 2010

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

Re: About Famix-Core-GuillermoSchwarz.123