Smaller mcd

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Smaller mcd

Nicolas Cellier
Hi all,
While reviewing some contributions, I saw this: Monticello-mva.667


Browse the whole thread, it's interesting.
How can we finish the job and make it happen?


Reply | Threaded
Open this post in threaded view
|

Re: Smaller mcd

David T. Lewis
On Thu, Mar 05, 2020 at 10:34:52PM +0100, Nicolas Cellier wrote:
>  Hi all,
> While reviewing some contributions, I saw this: Monticello-mva.667
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-April/194057.html
>
> Browse the whole thread, it's interesting.
> How can we finish the job and make it happen?

Nicolas,

Thank you for reviving this thread. It is a very worthwhile proposal
and it is sad to think that we let it drop for so long. Milan Vavra
clearly put a lot of thought into this, and in the earlier discussion,
Bert gave the concept a nod of approval too.

If I understand the discussion correctly, there are a couple of potential
issues that may need to be addressed concerning possible impact of
source.squeak.org and squeaksource.com and ss3, but I'm sure we can
follow up on those issues. Aside from that, there seems to be no reason
that this cannot be tested, reviewed, and moved into trunk.

I am saying this without haviing actually tested it myself, but it
really does look like a good idea, and we should find a way to make
it happen.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Smaller mcd

Bert Freudenberg
On Thu, Mar 5, 2020 at 4:28 PM David T. Lewis <[hidden email]> wrote:
On Thu, Mar 05, 2020 at 10:34:52PM +0100, Nicolas Cellier wrote:
>  Hi all,
> While reviewing some contributions, I saw this: Monticello-mva.667
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-April/194057.html
>
> Browse the whole thread, it's interesting.
> How can we finish the job and make it happen?

Nicolas,

Thank you for reviving this thread. It is a very worthwhile proposal
and it is sad to think that we let it drop for so long. Milan Vavra
clearly put a lot of thought into this, and in the earlier discussion,
Bert gave the concept a nod of approval too.

If I understand the discussion correctly, there are a couple of potential
issues that may need to be addressed concerning possible impact of
source.squeak.org and squeaksource.com and ss3, but I'm sure we can
follow up on those issues. Aside from that, there seems to be no reason
that this cannot be tested, reviewed, and moved into trunk.

I am saying this without haviing actually tested it myself, but it
really does look like a good idea, and we should find a way to make
it happen.

Agreed, this looks worthwhile doing. 

The tricky part is the diffs generated by the server. We would need some extended naming scheme to indicate that the MC client is able to handle the pruned histories.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Smaller mcd

Nicolas Cellier


Le ven. 6 mars 2020 à 01:49, Bert Freudenberg <[hidden email]> a écrit :
On Thu, Mar 5, 2020 at 4:28 PM David T. Lewis <[hidden email]> wrote:
On Thu, Mar 05, 2020 at 10:34:52PM +0100, Nicolas Cellier wrote:
>  Hi all,
> While reviewing some contributions, I saw this: Monticello-mva.667
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-April/194057.html
>
> Browse the whole thread, it's interesting.
> How can we finish the job and make it happen?

Nicolas,

Thank you for reviving this thread. It is a very worthwhile proposal
and it is sad to think that we let it drop for so long. Milan Vavra
clearly put a lot of thought into this, and in the earlier discussion,
Bert gave the concept a nod of approval too.

If I understand the discussion correctly, there are a couple of potential
issues that may need to be addressed concerning possible impact of
source.squeak.org and squeaksource.com and ss3, but I'm sure we can
follow up on those issues. Aside from that, there seems to be no reason
that this cannot be tested, reviewed, and moved into trunk.

I am saying this without haviing actually tested it myself, but it
really does look like a good idea, and we should find a way to make
it happen.

Agreed, this looks worthwhile doing. 

The tricky part is the diffs generated by the server. We would need some extended naming scheme to indicate that the MC client is able to handle the pruned histories.

- Bert -

As I understand it, there are two issues:
1)  the server must serve both old image without short history support, and uptodate images
 therefore, some discrimination has to happen in the query
 AND
 code for generating short and long mcd must coexist
2) old and new images might share a common package-cache, and old image shall not use mcd with shorten history
 The thread contains some proposals for preventing such accidental shortage...