12 Oct
2010
12 Oct
'10
6:56 p.m.
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:
--
Simon
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 
12 Oct
12 Oct
7:08 p.m.
New subject: About Famix-Core-GuillermoSchwarz.123
Yes, we will meet on Thursday.
Alexandre
On 12 Oct 2010, at 13:56, Simon Denier wrote:
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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:
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
5113
days inactive
5113
days old
1 comments
2 participants
participants (2)
-
Alexandre Bergel -
Simon Denier