Monticello: committing part of a change

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

Monticello: committing part of a change

Frank Shearar
I often find that in the middle of some large change I see a small thing
that needs correcting. Often, I just fix it and carry on hacking.

Usually - with git or mercurial - I'll commit just that small change
separately, so it's clear what's going on.

Is there any way to do something similar in Monticello? What's the usual
workflow people use to selectively commit a change?

frank

Reply | Threaded
Open this post in threaded view
|

Re: Monticello: committing part of a change

Chris Muller-3
Not the only way, but:

1) Select the Package containing the changes in the MC browser.  Click
"Changes" button.
2) File-out small, individual changes separately.
3) Save image.  Then save image again as: temp.image
4) Revert the package.
5) File-in changes from step 2.
6) Version package.
7) Exit temp.image, go back to your old image.
8) Merge package just saved.


On Sat, Feb 5, 2011 at 5:31 PM, Frank Shearar
<[hidden email]> wrote:

> I often find that in the middle of some large change I see a small thing
> that needs correcting. Often, I just fix it and carry on hacking.
>
> Usually - with git or mercurial - I'll commit just that small change
> separately, so it's clear what's going on.
>
> Is there any way to do something similar in Monticello? What's the usual
> workflow people use to selectively commit a change?
>
> frank
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Monticello: committing part of a change

Frank Shearar
On 2011/02/07 16:06, Chris Muller wrote:

> Not the only way, but:
>
> 1) Select the Package containing the changes in the MC browser.  Click
> "Changes" button.
> 2) File-out small, individual changes separately.
> 3) Save image.  Then save image again as: temp.image
> 4) Revert the package.
> 5) File-in changes from step 2.
> 6) Version package.
> 7) Exit temp.image, go back to your old image.
> 8) Merge package just saved.

I was hoping you weren't going to say that. A whole lot of work for what
should be very easy.

OK, I see that when one hits the Save button, Monticello creates the new
version using MCWorkingCopy>>newVersion, which ultimately calls
MCPackage>>snapshot. This returns an MCSnapshot containing a collection
of MCDefinitions for all the bits & pieces inside a package - class
definitions, method definitions, etc.

So presumably one could save SOME of the pending changes, by simply
saving an MCSnapshot that contains only SOME of the definitions in a
package?

frank

> On Sat, Feb 5, 2011 at 5:31 PM, Frank Shearar
> <[hidden email]>  wrote:
>> I often find that in the middle of some large change I see a small thing
>> that needs correcting. Often, I just fix it and carry on hacking.
>>
>> Usually - with git or mercurial - I'll commit just that small change
>> separately, so it's clear what's going on.
>>
>> Is there any way to do something similar in Monticello? What's the usual
>> workflow people use to selectively commit a change?
>>
>> frank
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Monticello: committing part of a change

Colin Putney-3
On Mon, Feb 14, 2011 at 2:24 PM, Frank Shearar
<[hidden email]> wrote:
> On 2011/02/07 16:06, Chris Muller wrote:

> OK, I see that when one hits the Save button, Monticello creates the new
> version using MCWorkingCopy>>newVersion, which ultimately calls
> MCPackage>>snapshot. This returns an MCSnapshot containing a collection of
> MCDefinitions for all the bits & pieces inside a package - class
> definitions, method definitions, etc.
>
> So presumably one could save SOME of the pending changes, by simply saving
> an MCSnapshot that contains only SOME of the definitions in a package?

The basic problem here is this: MC works by saving snapshots of
packages. When it loads a snapshot, it makes the code in the package
match what's recorded in the snapshot. That includes *removing* code
that's in the image and part of the package, but not in the snapshot.
So if you have a snapshot that only includes some of the definitions,
when you try to load it, everything else will be deleted.

Now, there's a few ways to work around it, but they all have issues.
One way is to include all the definitions, but only take some of them
from the image, and take the rest from the previous version of the
package. That should get you a complete, but it has a subtler problem:
the code in the "snapshot" never existed in your image. It may not
have enough internal consistency to be loadable. It might have methods
for classes that don't exist, or references to instance variables that
don't exist etc. Rather than deal with all those issues, Monticello
just relies on the regular Smalltalk mechanisms for ensuring that the
system is internally consistent.

Another way would be to create a sort of custom package definition,
which would allow the snapshot to contain just the changes you're
interested in, without wiping out the rest of the package  when you
load it. But then you need a way to manage that package definition, a
way to load it into the image before you load the snapshot, or a way
to bundle into the version file. That's pretty non-trivial - if we had
that, we wouldn't need PackageInfo.

For what it's worth, you can do it in Monticello 2 by creating a
change set before you make the fix, then taking a snapshot of the
change set.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Monticello: committing part of a change

Levente Uzonyi-2
In reply to this post by Frank Shearar
On Mon, 14 Feb 2011, Frank Shearar wrote:

> On 2011/02/07 16:06, Chris Muller wrote:
>> Not the only way, but:
>>
>> 1) Select the Package containing the changes in the MC browser.  Click
>> "Changes" button.
>> 2) File-out small, individual changes separately.
>> 3) Save image.  Then save image again as: temp.image
>> 4) Revert the package.
>> 5) File-in changes from step 2.
>> 6) Version package.
>> 7) Exit temp.image, go back to your old image.
>> 8) Merge package just saved.
>
> I was hoping you weren't going to say that. A whole lot of work for what
> should be very easy.
>
> OK, I see that when one hits the Save button, Monticello creates the new
> version using MCWorkingCopy>>newVersion, which ultimately calls
> MCPackage>>snapshot. This returns an MCSnapshot containing a collection of
> MCDefinitions for all the bits & pieces inside a package - class definitions,
> method definitions, etc.
>
> So presumably one could save SOME of the pending changes, by simply saving an
> MCSnapshot that contains only SOME of the definitions in a package?

Sound reasonable. We need to change the UI to let the user select the
changes s/he wants to save. It would also be nice to let the user create a
changeset from the selected changes.


Levente

>
> frank
>
>> On Sat, Feb 5, 2011 at 5:31 PM, Frank Shearar
>> <[hidden email]>  wrote:
>>> I often find that in the middle of some large change I see a small thing
>>> that needs correcting. Often, I just fix it and carry on hacking.
>>>
>>> Usually - with git or mercurial - I'll commit just that small change
>>> separately, so it's clear what's going on.
>>>
>>> Is there any way to do something similar in Monticello? What's the usual
>>> workflow people use to selectively commit a change?
>>>
>>> frank
>>>
>>>
>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

MC2? (was Re: [squeak-dev] Monticello: committing part of a change)

Casey Ransberger-2
Whatever happened to MC2 anyway? We currently use a fork of MC, no? In the longer term, does MC2 make more sense? Can we merge the changes from Trunk (e.g. atomic loading) into MC2? How much work would that be?

I regularly hear people asking for feature x and see replies to the effect "MC2 does that." So it seems like it meets some wants, if not needs. Are there objections to MC2, is MC2 just not well baked, or is it just a lot of work that no one is excited about doing?

If the problem is the latter, maybe someone who knows a bit about MC with a spot of time should ask ESUG for a grant.

I tried doing a port of MC from trunk to Cuis one night, and I learned two things:

 - MC is complex (I expected this)
 - I don't understand MC well enough to port it yet. Got the UI and networking going but that was as far as I could go without hitting the low limit of my understanding

On Feb 15, 2011, at 8:26 AM, Levente Uzonyi <[hidden email]> wrote:

> On Mon, 14 Feb 2011, Frank Shearar wrote:
>
>> On 2011/02/07 16:06, Chris Muller wrote:
>>> Not the only way, but:
>>> 1) Select the Package containing the changes in the MC browser.  Click
>>> "Changes" button.
>>> 2) File-out small, individual changes separately.
>>> 3) Save image.  Then save image again as: temp.image
>>> 4) Revert the package.
>>> 5) File-in changes from step 2.
>>> 6) Version package.
>>> 7) Exit temp.image, go back to your old image.
>>> 8) Merge package just saved.
>>
>> I was hoping you weren't going to say that. A whole lot of work for what should be very easy.
>>
>> OK, I see that when one hits the Save button, Monticello creates the new version using MCWorkingCopy>>newVersion, which ultimately calls MCPackage>>snapshot. This returns an MCSnapshot containing a collection of MCDefinitions for all the bits & pieces inside a package - class definitions, method definitions, etc.
>>
>> So presumably one could save SOME of the pending changes, by simply saving an MCSnapshot that contains only SOME of the definitions in a package?
>
> Sound reasonable. We need to change the UI to let the user select the changes s/he wants to save. It would also be nice to let the user create a changeset from the selected changes.
>
>
> Levente
>
>>
>> frank
>>
>>> On Sat, Feb 5, 2011 at 5:31 PM, Frank Shearar
>>> <[hidden email]>  wrote:
>>>> I often find that in the middle of some large change I see a small thing
>>>> that needs correcting. Often, I just fix it and carry on hacking.
>>>> Usually - with git or mercurial - I'll commit just that small change
>>>> separately, so it's clear what's going on.
>>>> Is there any way to do something similar in Monticello? What's the usual
>>>> workflow people use to selectively commit a change?
>>>> frank
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: MC2? (was Re: [squeak-dev] Monticello: committing part of a change)

Ken G. Brown
Here are some the links re: MC2 that I have saved:

<http://map1.squeakfoundation.org/package/44f9f9fb-0a45-4c16-9a10-b2885eefa8da>
<http://www.squeaksource.com/Monticello2/>
<http://wiki.squeak.org/squeak/5624>
<http://blog.summer.squeak.org/2007/06/start-coding-on-monticello-2.html>

Ken G. Brown

At 10:44 AM -0800 2/15/11, Casey Ransberger apparently wrote:

>Whatever happened to MC2 anyway? We currently use a fork of MC, no? In the longer term, does MC2 make more sense? Can we merge the changes from Trunk (e.g. atomic loading) into MC2? How much work would that be?
>
>I regularly hear people asking for feature x and see replies to the effect "MC2 does that." So it seems like it meets some wants, if not needs. Are there objections to MC2, is MC2 just not well baked, or is it just a lot of work that no one is excited about doing?
>
>If the problem is the latter, maybe someone who knows a bit about MC with a spot of time should ask ESUG for a grant.
>
>I tried doing a port of MC from trunk to Cuis one night, and I learned two things:
>
> - MC is complex (I expected this)
> - I don't understand MC well enough to port it yet. Got the UI and networking going but that was as far as I could go without hitting the low limit of my understanding
>
>On Feb 15, 2011, at 8:26 AM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Mon, 14 Feb 2011, Frank Shearar wrote:
>>
>>> On 2011/02/07 16:06, Chris Muller wrote:
>>>> Not the only way, but:
>>>> 1) Select the Package containing the changes in the MC browser.  Click
>>>> "Changes" button.
>>>> 2) File-out small, individual changes separately.
>>>> 3) Save image.  Then save image again as: temp.image
>>>> 4) Revert the package.
>>>> 5) File-in changes from step 2.
>>>> 6) Version package.
>>>> 7) Exit temp.image, go back to your old image.
>>>> 8) Merge package just saved.
>>>
>>> I was hoping you weren't going to say that. A whole lot of work for what should be very easy.
>>>
>>> OK, I see that when one hits the Save button, Monticello creates the new version using MCWorkingCopy>>newVersion, which ultimately calls MCPackage>>snapshot. This returns an MCSnapshot containing a collection of MCDefinitions for all the bits & pieces inside a package - class definitions, method definitions, etc.
>>>
>>> So presumably one could save SOME of the pending changes, by simply saving an MCSnapshot that contains only SOME of the definitions in a package?
>>
>> Sound reasonable. We need to change the UI to let the user select the changes s/he wants to save. It would also be nice to let the user create a changeset from the selected changes.
>>
>>
>> Levente
>>
>>>
>>> frank
>>>
>>>> On Sat, Feb 5, 2011 at 5:31 PM, Frank Shearar
>>>> <[hidden email]>  wrote:
>>>>> I often find that in the middle of some large change I see a small thing
>>>>> that needs correcting. Often, I just fix it and carry on hacking.
>>>>> Usually - with git or mercurial - I'll commit just that small change
>>>>> separately, so it's clear what's going on.
>>>>> Is there any way to do something similar in Monticello? What's the usual
>>>>> workflow people use to selectively commit a change?
>>>>> frank
>>>
>>>
>>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: MC2? (was Re: [squeak-dev] Monticello: committing part of a change)

Bert Freudenberg
In reply to this post by Casey Ransberger-2
MC2 is not an extension of MC but a complete "rethink". I have the impression that MC is not hurting badly enough so people would actually try MC2. Having "private" hacks in my image while still being able to upload a "clean" package seems like a really good incentive to give it a spin :)

- Bert -

On 15.02.2011, at 19:44, Casey Ransberger wrote:

> Whatever happened to MC2 anyway? We currently use a fork of MC, no? In the longer term, does MC2 make more sense? Can we merge the changes from Trunk (e.g. atomic loading) into MC2? How much work would that be?
>
> I regularly hear people asking for feature x and see replies to the effect "MC2 does that." So it seems like it meets some wants, if not needs. Are there objections to MC2, is MC2 just not well baked, or is it just a lot of work that no one is excited about doing?
>
> If the problem is the latter, maybe someone who knows a bit about MC with a spot of time should ask ESUG for a grant.
>
> I tried doing a port of MC from trunk to Cuis one night, and I learned two things:
>
> - MC is complex (I expected this)
> - I don't understand MC well enough to port it yet. Got the UI and networking going but that was as far as I could go without hitting the low limit of my understanding
>
> On Feb 15, 2011, at 8:26 AM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Mon, 14 Feb 2011, Frank Shearar wrote:
>>
>>> On 2011/02/07 16:06, Chris Muller wrote:
>>>> Not the only way, but:
>>>> 1) Select the Package containing the changes in the MC browser.  Click
>>>> "Changes" button.
>>>> 2) File-out small, individual changes separately.
>>>> 3) Save image.  Then save image again as: temp.image
>>>> 4) Revert the package.
>>>> 5) File-in changes from step 2.
>>>> 6) Version package.
>>>> 7) Exit temp.image, go back to your old image.
>>>> 8) Merge package just saved.
>>>
>>> I was hoping you weren't going to say that. A whole lot of work for what should be very easy.
>>>
>>> OK, I see that when one hits the Save button, Monticello creates the new version using MCWorkingCopy>>newVersion, which ultimately calls MCPackage>>snapshot. This returns an MCSnapshot containing a collection of MCDefinitions for all the bits & pieces inside a package - class definitions, method definitions, etc.
>>>
>>> So presumably one could save SOME of the pending changes, by simply saving an MCSnapshot that contains only SOME of the definitions in a package?
>>
>> Sound reasonable. We need to change the UI to let the user select the changes s/he wants to save. It would also be nice to let the user create a changeset from the selected changes.
>>
>>
>> Levente
>>
>>>
>>> frank
>>>
>>>> On Sat, Feb 5, 2011 at 5:31 PM, Frank Shearar
>>>> <[hidden email]>  wrote:
>>>>> I often find that in the middle of some large change I see a small thing
>>>>> that needs correcting. Often, I just fix it and carry on hacking.
>>>>> Usually - with git or mercurial - I'll commit just that small change
>>>>> separately, so it's clear what's going on.
>>>>> Is there any way to do something similar in Monticello? What's the usual
>>>>> workflow people use to selectively commit a change?
>>>>> frank
>>>
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Monticello: committing part of a change

Frank Shearar
In reply to this post by Colin Putney-3
On 2011/02/15 03:54, Colin Putney wrote:

> On Mon, Feb 14, 2011 at 2:24 PM, Frank Shearar
> <[hidden email]>  wrote:
>> On 2011/02/07 16:06, Chris Muller wrote:
>
>> OK, I see that when one hits the Save button, Monticello creates the new
>> version using MCWorkingCopy>>newVersion, which ultimately calls
>> MCPackage>>snapshot. This returns an MCSnapshot containing a collection of
>> MCDefinitions for all the bits&  pieces inside a package - class
>> definitions, method definitions, etc.
>>
>> So presumably one could save SOME of the pending changes, by simply saving
>> an MCSnapshot that contains only SOME of the definitions in a package?
>
> The basic problem here is this: MC works by saving snapshots of
> packages. When it loads a snapshot, it makes the code in the package
> match what's recorded in the snapshot. That includes *removing* code
> that's in the image and part of the package, but not in the snapshot.
> So if you have a snapshot that only includes some of the definitions,
> when you try to load it, everything else will be deleted.
>
> Now, there's a few ways to work around it, but they all have issues.
> One way is to include all the definitions, but only take some of them
> from the image, and take the rest from the previous version of the
> package. That should get you a complete, but it has a subtler problem:
> the code in the "snapshot" never existed in your image. It may not
> have enough internal consistency to be loadable. It might have methods
> for classes that don't exist, or references to instance variables that
> don't exist etc. Rather than deal with all those issues, Monticello
> just relies on the regular Smalltalk mechanisms for ensuring that the
> system is internally consistent.
>
> Another way would be to create a sort of custom package definition,
> which would allow the snapshot to contain just the changes you're
> interested in, without wiping out the rest of the package  when you
> load it. But then you need a way to manage that package definition, a
> way to load it into the image before you load the snapshot, or a way
> to bundle into the version file. That's pretty non-trivial - if we had
> that, we wouldn't need PackageInfo.
>
> For what it's worth, you can do it in Monticello 2 by creating a
> change set before you make the fix, then taking a snapshot of the
> change set.

Since we're not using MC2 (I see the thread's spawning a conversation
around that), how about this:

* Let M be the package version number.
* save the current package as a snapshot with version N, where N >= M + 1.
* Roll back the package to version M. Present the user with a list of
changes between N and M.
* Save this new half-package with version M + 1.
* Roll back to M, and load package N. (Rolling back to M might not be
necessary?) _Delete_ version N.

frank

Reply | Threaded
Open this post in threaded view
|

Re: MC2? (was Re: [squeak-dev] Monticello: committing part of a change)

Colin Putney-3
In reply to this post by Casey Ransberger-2
On Tue, Feb 15, 2011 at 10:44 AM, Casey Ransberger
<[hidden email]> wrote:

> Whatever happened to MC2 anyway? We currently use a fork of MC, no? In the longer term, does MC2 make more sense? Can we merge the changes from Trunk (e.g. atomic loading) into MC2? How much work would that be?
>
> I regularly hear people asking for feature x and see replies to the effect "MC2 does that." So it seems like it meets some wants, if not needs. Are there objections to MC2, is MC2 just not well baked, or is it just a lot of work that no one is excited about doing?
>
> If the problem is the latter, maybe someone who knows a bit about MC with a spot of time should ask ESUG for a grant.
>
> I tried doing a port of MC from trunk to Cuis one night, and I learned two things:
>
>  - MC is complex (I expected this)
>  - I don't understand MC well enough to port it yet. Got the UI and networking going but that was as far as I could go without hitting the low limit of my understanding

Bert's right. MC2 is a rethink, applying what we've learned from MC1
to a ground-up rewrite.

The current release of MC2 is stable and usable, but it has some
workflow issues that make it impractical for projects with a lot of
contributors. The bleeding-edge version of MC2 solves these issues (I
think), but it's incomplete and unusable.

MC2 doesn't move forward very fast because 1) MC1 is good enough for
the most part and 2) the folks that contribute don't have a lot of
spare time. It *is* moving forward, though, and I expect we'll get to
a solid, usable release eventually.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: MC2? (was Re: [squeak-dev] Monticello: committing part of a change)

Frank Shearar
On 2011/02/15 21:23, Colin Putney wrote:

> On Tue, Feb 15, 2011 at 10:44 AM, Casey Ransberger
> <[hidden email]>  wrote:
>> Whatever happened to MC2 anyway? We currently use a fork of MC, no? In the longer term, does MC2 make more sense? Can we merge the changes from Trunk (e.g. atomic loading) into MC2? How much work would that be?
>>
>> I regularly hear people asking for feature x and see replies to the effect "MC2 does that." So it seems like it meets some wants, if not needs. Are there objections to MC2, is MC2 just not well baked, or is it just a lot of work that no one is excited about doing?
>>
>> If the problem is the latter, maybe someone who knows a bit about MC with a spot of time should ask ESUG for a grant.
>>
>> I tried doing a port of MC from trunk to Cuis one night, and I learned two things:
>>
>>   - MC is complex (I expected this)
>>   - I don't understand MC well enough to port it yet. Got the UI and networking going but that was as far as I could go without hitting the low limit of my understanding
>
> Bert's right. MC2 is a rethink, applying what we've learned from MC1
> to a ground-up rewrite.
>
> The current release of MC2 is stable and usable, but it has some
> workflow issues that make it impractical for projects with a lot of
> contributors. The bleeding-edge version of MC2 solves these issues (I
> think), but it's incomplete and unusable.
>
> MC2 doesn't move forward very fast because 1) MC1 is good enough for
> the most part and 2) the folks that contribute don't have a lot of
> spare time. It *is* moving forward, though, and I expect we'll get to
> a solid, usable release eventually.

In case you're trying to find MC2, it looks like the new/latest home is
here: http://source.wiresong.ca/mc

frank

Reply | Threaded
Open this post in threaded view
|

Re: MC2? (was Re: [squeak-dev] Monticello: committing part of a change)

Frank Shearar
On 2011/02/17 09:02, Frank Shearar wrote:

> On 2011/02/15 21:23, Colin Putney wrote:
>> On Tue, Feb 15, 2011 at 10:44 AM, Casey Ransberger
>> <[hidden email]> wrote:
>>> Whatever happened to MC2 anyway? We currently use a fork of MC, no?
>>> In the longer term, does MC2 make more sense? Can we merge the
>>> changes from Trunk (e.g. atomic loading) into MC2? How much work
>>> would that be?
>>>
>>> I regularly hear people asking for feature x and see replies to the
>>> effect "MC2 does that." So it seems like it meets some wants, if not
>>> needs. Are there objections to MC2, is MC2 just not well baked, or is
>>> it just a lot of work that no one is excited about doing?
>>>
>>> If the problem is the latter, maybe someone who knows a bit about MC
>>> with a spot of time should ask ESUG for a grant.
>>>
>>> I tried doing a port of MC from trunk to Cuis one night, and I
>>> learned two things:
>>>
>>> - MC is complex (I expected this)
>>> - I don't understand MC well enough to port it yet. Got the UI and
>>> networking going but that was as far as I could go without hitting
>>> the low limit of my understanding
>>
>> Bert's right. MC2 is a rethink, applying what we've learned from MC1
>> to a ground-up rewrite.
>>
>> The current release of MC2 is stable and usable, but it has some
>> workflow issues that make it impractical for projects with a lot of
>> contributors. The bleeding-edge version of MC2 solves these issues (I
>> think), but it's incomplete and unusable.
>>
>> MC2 doesn't move forward very fast because 1) MC1 is good enough for
>> the most part and 2) the folks that contribute don't have a lot of
>> spare time. It *is* moving forward, though, and I expect we'll get to
>> a solid, usable release eventually.
>
> In case you're trying to find MC2, it looks like the new/latest home is
> here: http://source.wiresong.ca/mc

That's the repository itself. I found the definitive Download Place -
http://www.wiresong.ca/downloads - buried in the Getting Started part of
the documentation (who reads that?!) at
http://www.wiresong.ca/monticello/v2/docs, which is itself readily
googleable.

frank