Method versioning in Pharo images

I would like to know if the past history of the method's versions has been lost by design or accident.

In the core image for example it is possible only for the method Object>>at: an entry "yo 6/29/2004 11:39".

Are we considering the implementation of Pharo as a clean slate and we'll start from some epoch date?

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Nov 28, 2009, at 9:42 PM, [hidden email] wrote:

> I would like to know if the past history of the method's versions has been lost by design or accident.
>
> In the core image for example it is possible only for the method Object>>at: an entry "yo 6/29/2004 11:39".
>
> Are we considering the implementation of Pharo as a clean slate and we'll start from some epoch date?

We had to make new .sources for 1.0... and even if not: the problem is that the .changes can only
be 32MB, and that is reached fast. In 3.9, we even had to condense changes in the middle of the release cycle.
(This is what you get from never moving on from outdated technology....)

What I would want to have is a server with all old code that than is queried by the image...

        Marcus



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Em 28/11/2009 21:19, Marcus Denker < [hidden email] > escreveu:

>  On Nov 28, 2009, at 9:42 PM, [hidden email] wrote:
>
> > I would like to know if  the past history of the method's versions
> >has been lost by design or accident.
> > In the core  image for example it is possible  only for the method
> > Object>>at: an entry "yo 6/29/2004 11:39".
> > Are we  considering the implementation  of Pharo as a  clean slate
> > and we'll start from some epoch date?

>  We had to make new .sources for 1.0... and even if not: the problem
> is that the .changes can only  be 32MB, and that is reached fast. In
> 3.9, we  even had to condense  changes in the middle  of the release
> cycle.  (This  is what  you get from  never moving on  from outdated
> technology....)

I see.  Then is an enviromental imposition ;-)

>  What I would want  to have is a server with all  old code that than
> is queried by the image...

Marcus,  let  me ask to put  in this  wish  list we could have  then a
versioning  system similar  to RCS/CVS  and family where  you name (in
fact  you number and  give then alias  names, but I  digress. . .) the
versions  and can  put  comments documenting the code  changes for the
non obvious things in code.
 
An escape hatch  for the .changes limit would  be to serialize all the
versioning information in a .versions file.

--
Cesar Rabak


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Nov 29, 2009, at 1:27 AM, [hidden email] wrote:
>
>> What I would want  to have is a server with all  old code that than
>> is queried by the image...
>
> Marcus,  let  me ask to put  in this  wish  list we could have  then a
> versioning  system similar  to RCS/CVS  and family where  you name (in
> fact  you number and  give then alias  names, but I  digress. . .) the
> versions  and can  put  comments documenting the code  changes for the
> non obvious things in code.

Yes... we do have MC, but those compressed .zip snapshots are not really
good as a history model to query (the information is there, but you need to
anpack all zips...)

One important thing that needs to be done is to move on from having multiple
mechanism in parallel (sources + changes, MC) to one.

>
> An escape hatch  for the .changes limit would  be to serialize all the
> versioning information in a .versions file.

yes, but it would be very large.

        Marcus

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker wrote:

> What I would want to have is a server with all old code that than is
> queried by the image...

Almost a year ago I did some work on a database, but then it got stuck
on the back burner.
What would be helpful in the future would be to have unique ids for
every method, class version etc. I think Craig did this in Spoon.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

One thing that I like about the split (image, changes, sources) approach is that the changes seldom go bad, providing a lot of protection against lost work.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Marcus Denker
Sent: Sunday, November 29, 2009 3:26 AM
To: [hidden email]
Subject: Re: [Pharo-project] Method versioning in Pharo images


On Nov 29, 2009, at 1:27 AM, [hidden email] wrote:
>
>> What I would want  to have is a server with all  old code that than
>> is queried by the image...
>
> Marcus,  let  me ask to put  in this  wish  list we could have  then a
> versioning  system similar  to RCS/CVS  and family where  you name (in
> fact  you number and  give then alias  names, but I  digress. . .) the
> versions  and can  put  comments documenting the code  changes for the
> non obvious things in code.

Yes... we do have MC, but those compressed .zip snapshots are not really good as a history model to query (the information is there, but you need to anpack all zips...)

One important thing that needs to be done is to move on from having multiple mechanism in parallel (sources + changes, MC) to one.

>
> An escape hatch  for the .changes limit would  be to serialize all the
> versioning information in a .versions file.

yes, but it would be very large.

        Marcus

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Nov 29, 2009, at 2:48 PM, Schwab,Wilhelm K wrote:

> One thing that I like about the split (image, changes, sources) approach is that the changes seldom go bad, providing a lot of protection against lost work.
>


But having a log of commited methods and doits is independend of where the source is saved, and especially independend of a source repository.

Of course, you want keep the changelog.... but only for that: a log.

        Marcus




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

However, for "independent" read "redundant."  Take away the redundancy, and there is a single point of failure.  That keeps surfacing as a good idea, and I fear the backlash once the redundancy gets removed in the name of saving space.

What is the source of the change log size limit?




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Marcus Denker
Sent: Sunday, November 29, 2009 8:55 AM
To: [hidden email]
Subject: Re: [Pharo-project] Method versioning in Pharo images


On Nov 29, 2009, at 2:48 PM, Schwab,Wilhelm K wrote:

> One thing that I like about the split (image, changes, sources) approach is that the changes seldom go bad, providing a lot of protection against lost work.
>


But having a log of commited methods and doits is independend of where the source is saved, and especially independend of a source repository.

Of course, you want keep the changelog.... but only for that: a log.

        Marcus




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Nov 29, 2009, at 6:15 PM, Schwab,Wilhelm K wrote:

> However, for "independent" read "redundant."  Take away the redundancy, and there is a single point of failure.  That keeps surfacing as a good idea, and I fear the backlash once the redundancy gets removed in the name of saving space.
>
but if you want redunancy, provide a service that does that. One thing. And than reuse it.

A log of course would provide redundancy. That's the definition. The only difference is that it would *only be a log*, and nothing else.

> What is the source of the change log size limit?
>

32MB.

        Marcus
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Marcus Denker wrote:
> On Nov 29, 2009, at 6:15 PM, Schwab,Wilhelm K wrote:
>
>> What is the source of the change log size limit?
>>
>
> 32MB.

Would it be possible with the current compiled method format to make the
source pointer a first class object?

A looong time ago I did that in VW and used it to keep most of the
sources in package files, reducing the size of the change log by quite a
bit. It would allow to have the source point to some remote location.

Michael


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Nov 29, 2009, at 6:27 PM, Michael Rueger wrote:

yes.... now that there is a way to have state in methods, this is no problem.

> A looong time ago I did that in VW and used it to keep most of the
> sources in package files, reducing the size of the change log by quite a
> bit. It would allow to have the source point to some remote location.
>

        Marcus


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Yes, but why 32MB?




-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Marcus Denker
Sent: Sunday, November 29, 2009 12:18 PM
To: [hidden email]
Subject: Re: [Pharo-project] Method versioning in Pharo images


On Nov 29, 2009, at 6:15 PM, Schwab,Wilhelm K wrote:

> However, for "independent" read "redundant."  Take away the redundancy, and there is a single point of failure.  That keeps surfacing as a good idea, and I fear the backlash once the redundancy gets removed in the name of saving space.
>
but if you want redunancy, provide a service that does that. One thing. And than reuse it.

A log of course would provide redundancy. That's the definition. The only difference is that it would *only be a log*, and nothing else.

> What is the source of the change log size limit?
>

32MB.

        Marcus
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Yes, but why 32MB?

The pointer in the compiled method has only that size (presumabely 25 bits).

Note that there is an efficient distributed database format for an
ininite number of changes available. It is called Monticello 2.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> We had to make new .sources for 1.0... and even if not: the problem is that the .changes can only
> be 32MB, and that is reached fast. In 3.9, we even had to condense changes in the middle of the release cycle.
> (This is what you get from never moving on from outdated technology....)
>
> What I would want to have is a server with all old code that than is queried by the image...

yes but somebody else should code it because our plate is full.

Stef
>
> Marcus

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael

do you have this code somewhere?
Because veronica will probably build something in that vein for her PhD on versioning.

Stef

On Nov 29, 2009, at 10:59 AM, Michael Rueger wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse wrote:
> Michael
>
> do you have this code somewhere?

Yes, need to package it up.

It uses glorp and a postgres database as the backend.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project