David T. Lewis uploaded a new version of Monticello to project The Inbox: http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Motivated by the exercise of preparing to copy Chronology-Core versions from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category 'morphic ui') ----- defaultExtent + ^600@300! - ^450@300!
Item was added: + ----- Method: MCVersion>>reparent (in category 'actions') ----- + reparent + "Let aNode be the sole parent of this version" + self workingCopy reparent: self!
Item was changed: ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic ui') ----- buttonSpecs + ^#( + ('Refresh' refresh 'refresh the version-list') - ^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion) + (History history 'Browse the history of this version' hasVersion) + (Changes changes 'Browse the changes this version would make to the image' hasVersion) + (Load load 'Load this version into the image' hasVersion) + (Merge merge 'Merge this version into the image' hasVersion) + (Adopt adopt 'Adopt this version as an ancestor of your working copy' hasVersion) + (Reparent reparent 'Adopt this version as the sole ancestor of your working copy' hasVersion) + (Copy save 'Copy this version to another repository' hasVersion) + (Diff diff 'Create an equivalent version based on an earlier release' hasVersion) + )! - (History history 'Browse the history of this version' hasVersion) - (Changes changes 'Browse the changes this version would make to the - image' hasVersion) - (Load load 'Load this version into the image' hasVersion) - (Merge merge 'Merge this version into the image' hasVersion) - (Adopt adopt 'Adopt this version as an ancestor of your working copy' - hasVersion) - (Copy save 'Copy this version to another repository' hasVersion) - (Diff diff 'Create an equivalent version based on an earlier release' - hasVersion))!
Item was added: + ----- Method: MCVersionInspector>>reparent (in category 'accessing') ----- + reparent + (self confirm:'Adopt ',self version info name, ' as the sole ancestor of your working copy?') + ifTrue: [self version reparent]!
Item was added: + ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet unclassified') ----- + reparent: aNode + "Let aNode be the sole parent of this version" + ancestors := Array with: aNode + !
Item was added: + ----- Method: MCWorkingCopy>>reparent: (in category 'operations') ----- + reparent: aVersion + "Let aNode be the sole parent of this version" + ancestry reparent: aVersion info. + self changed.!
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Monticello to project The Inbox: http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Nice. It is for someone like Bert to review and accept this but this seems a very useful addition to me!
Motivated by the exercise of preparing to copy Chronology-Core versions from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category 'morphic ui') ----- defaultExtent
^600@300!
^450@300!Item was added:
- ----- Method: MCVersion>>reparent (in category 'actions') -----
- reparent
"Let aNode be the sole parent of this version"self workingCopy reparent: self!Item was changed:
----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic ui')
buttonSpecs
^#(('Refresh' refresh 'refresh the version-list')
^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion)
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this version wouldmake to the image' hasVersion)
(Load load 'Load this version into the image' hasVersion)(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor of yourworking copy' hasVersion)
(Reparent reparent 'Adopt this version as the soleancestor of your working copy' hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release' hasVersion)
)!
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this version wouldmake to the
- image' hasVersion)
(Load load 'Load this version into the image' hasVersion)(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor of yourworking copy'
- hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release'
- hasVersion))!
Item was added:
- ----- Method: MCVersionInspector>>reparent (in category 'accessing')
- reparent
(self confirm:'Adopt ',self version info name, ' as the soleancestor of your working copy?')
ifTrue: [self version reparent]!Item was added:
- ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
unclassified') -----
- reparent: aNode
"Let aNode be the sole parent of this version"ancestors := Array with: aNode- !
Item was added:
- ----- Method: MCWorkingCopy>>reparent: (in category 'operations') -----
- reparent: aVersion
"Let aNode be the sole parent of this version"ancestry reparent: aVersion info.self changed.!
You read my mind! I didn't review or test it, but I was already thinking about this functionality to help us with Inbox submissions as well.
What I would like to propose is that we feel the need to rapid-fire multiple versions into trunk, to do it into Inbox instead, and when we have the final one ready for trunk, adopt the top version in trunk as the sole parent so that we can see just the _true_ change from the prior version, without all the noise of the "interim" changes.
I even think the user should be prompted to do so, but one step at a time...
Best, Chris On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Monticello to project The Inbox: http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Nice. It is for someone like Bert to review and accept this but this seems a very useful addition to me!
Motivated by the exercise of preparing to copy Chronology-Core versions from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category 'morphic ui') ----- defaultExtent
^600@300!
^450@300!Item was added:
- ----- Method: MCVersion>>reparent (in category 'actions') -----
- reparent
"Let aNode be the sole parent of this version"self workingCopy reparent: self!Item was changed: ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic ui') ----- buttonSpecs
^#(('Refresh' refresh 'refresh the version-list')
^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion)
(History history 'Browse the history of this version' hasVersion)(Changes changes 'Browse the changes this version would make to the image' hasVersion)(Load load 'Load this version into the image' hasVersion)(Merge merge 'Merge this version into the image' hasVersion)(Adopt adopt 'Adopt this version as an ancestor of your working copy' hasVersion)(Reparent reparent 'Adopt this version as the sole ancestor of your working copy' hasVersion)(Copy save 'Copy this version to another repository' hasVersion)(Diff diff 'Create an equivalent version based on an earlier release' hasVersion))!
(History history 'Browse the history of this version' hasVersion)(Changes changes 'Browse the changes this version would make to the- image' hasVersion)
(Load load 'Load this version into the image' hasVersion)(Merge merge 'Merge this version into the image' hasVersion)(Adopt adopt 'Adopt this version as an ancestor of your working copy'- hasVersion)
(Copy save 'Copy this version to another repository' hasVersion)(Diff diff 'Create an equivalent version based on an earlier release'- hasVersion))!
Item was added:
- ----- Method: MCVersionInspector>>reparent (in category 'accessing') -----
- reparent
(self confirm:'Adopt ',self version info name, ' as the sole ancestor of your working copy?')ifTrue: [self version reparent]!Item was added:
- ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet unclassified') -----
- reparent: aNode
"Let aNode be the sole parent of this version"ancestors := Array with: aNode- !
Item was added:
- ----- Method: MCWorkingCopy>>reparent: (in category 'operations') -----
- reparent: aVersion
"Let aNode be the sole parent of this version"ancestry reparent: aVersion info.self changed.!-- _,,,^..^,,,_ best, Eliot
I can see that use case, but meddling with history / parentage is not the right way to do it IMHO. (even the "adopt" button is questionable, except in very limited circumstances) It's too easy to lose changes that way - anything that happened in trunk up to this point from when you branched off would be lost (or it would be the responsibility of the developer to make sure this is not the case, which is way too fragile).
The "standard" way to do this is to do a "merge-and-squash" (standard as in, accepted practice in other developer communities, e.g. "git merge --squash").
This is like a merge (meaning it combines changes from both trunk and your line of commits) but throws away all the intermediate commits, "squashing" all the changes into one single merge commit. That means you can commit as much and as often as you like, but when merging it into trunk, it is only seen as one commit.
But let's ask David: what is your use case?
- Bert -
On Tue, Nov 6, 2018 at 10:37 AM Chris Muller asqueaker@gmail.com wrote:
You read my mind! I didn't review or test it, but I was already thinking about this functionality to help us with Inbox submissions as well.
What I would like to propose is that we feel the need to rapid-fire multiple versions into trunk, to do it into Inbox instead, and when we have the final one ready for trunk, adopt the top version in trunk as the sole parent so that we can see just the _true_ change from the prior version, without all the noise of the "interim" changes.
I even think the user should be prompted to do so, but one step at a time...
Best, Chris On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Monticello to project The
Inbox:
http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version
to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Nice. It is for someone like Bert to review and accept this but this
seems a very useful addition to me!
Motivated by the exercise of preparing to copy Chronology-Core versions
from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category
'morphic ui') -----
defaultExtent
^600@300!
^450@300!Item was added:
- ----- Method: MCVersion>>reparent (in category 'actions') -----
- reparent
"Let aNode be the sole parent of this version"self workingCopy reparent: self!Item was changed: ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic
ui') -----
buttonSpecs
^#(('Refresh' refresh 'refresh the version-list')
^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion)
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this version wouldmake to the image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor of yourworking copy' hasVersion)
(Reparent reparent 'Adopt this version as the soleancestor of your working copy' hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release' hasVersion)
)!
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this versionwould make to the
- image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor ofyour working copy'
- hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release'
- hasVersion))!
Item was added:
- ----- Method: MCVersionInspector>>reparent (in category 'accessing')
- reparent
(self confirm:'Adopt ',self version info name, ' as the soleancestor of your working copy?')
ifTrue: [self version reparent]!Item was added:
- ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
unclassified') -----
- reparent: aNode
"Let aNode be the sole parent of this version"ancestors := Array with: aNode- !
Item was added:
- ----- Method: MCWorkingCopy>>reparent: (in category 'operations')
- reparent: aVersion
"Let aNode be the sole parent of this version"ancestry reparent: aVersion info.self changed.!-- _,,,^..^,,,_ best, Eliot
I can see that use case, but meddling with history / parentage is not the right way to do it IMHO. (even the "adopt" button is questionable, except in very limited circumstances) It's too easy to lose changes that way - anything that happened in trunk up to this point from when you branched off would be lost (or it would be the responsibility of the developer to make sure this is not the case, which is way too fragile).
C'mon Bert, it's a basic developer responsibility anyway. It isn't any different or more "fragile" than someone committing a version that didn't merge changes since they started working on it. Why all these drama words like "meddling"? I call it making "quality commits"...
The "standard" way to do this is to do a "merge-and-squash" (standard as in, accepted practice in other developer communities, e.g. "git merge --squash").
Of course merging the latest trunk updates is *implied*, it's a basic dev responsibility, otherwise what one would be putting into trunk would not be correct in either case...
This is like a merge (meaning it combines changes from both trunk and your line of commits) but throws away all the intermediate commits, "squashing" all the changes into one single merge commit. That means you can commit as much and as often as you like, but when merging it into trunk, it is only seen as one commit.
That sounds great!
But let's ask David: what is your use case?
I think Dave's use case is the same as when we split Chronology from Kernel into its own "Chronology" package...
My use case is different.
Package Chronology-Core is part of the trunk update stream. Separate from this, and hosted in a squeaksource.com repository for UTCDateAndTime, I have a sequence of Chronology-Core versions that ends with a version that I would like to be able to submit into the existing trunk stream.
Both streams (Squeak trunk and SS UTCDateAndTime) are rooting in a common version Chronology-Core-cmm.2 of 3 March 2016. Both streams have progressed in parallel, and are (mostly) functionally equivalent.
I was looking for a way to move the squeaksource.com update stream into trunk without disrupting the existing update stream. A possible solution is to re-save the squeaksource.com versions as versions named 'Chronology-Core.UTC-xxx.nn.mcz' rather than 'Chronology-Core-xxx.nn.mcz'.
In order to do this, I loaded individual versions 'Chronology-Core-xxx.nn.mcz' from the squeaksource repository, then saved them as equivalent 'Chronology-Core.UTC-xxx.nn.mcz' versions in a local repository on my PC (that could later be copied to inbox or trunk if the experiment works).
As part of this process, it was necessary for me to load from one repository, then save to another using the '.UTC' naming. In order for this to work, I needed to be able to reparent the new '.UTC' version to its immediate predecessor in the new repository. This retains the '.UTC' naming throughout the new repository version histary, and results in a sequence of 'Chronology-Core.UTC-xxx.nn.mcz' versions in the new repository that is equivalent to the original, but separate from the naming conventions of the Squeak trunk update stream.
This is probably not a common use case ;-)
Dave
On Tue, Nov 06, 2018 at 02:12:19PM -0800, Bert Freudenberg wrote:
I can see that use case, but meddling with history / parentage is not the right way to do it IMHO. (even the "adopt" button is questionable, except in very limited circumstances) It's too easy to lose changes that way - anything that happened in trunk up to this point from when you branched off would be lost (or it would be the responsibility of the developer to make sure this is not the case, which is way too fragile).
The "standard" way to do this is to do a "merge-and-squash" (standard as in, accepted practice in other developer communities, e.g. "git merge --squash").
This is like a merge (meaning it combines changes from both trunk and your line of commits) but throws away all the intermediate commits, "squashing" all the changes into one single merge commit. That means you can commit as much and as often as you like, but when merging it into trunk, it is only seen as one commit.
But let's ask David: what is your use case?
- Bert -
On Tue, Nov 6, 2018 at 10:37 AM Chris Muller asqueaker@gmail.com wrote:
You read my mind! I didn't review or test it, but I was already thinking about this functionality to help us with Inbox submissions as well.
What I would like to propose is that we feel the need to rapid-fire multiple versions into trunk, to do it into Inbox instead, and when we have the final one ready for trunk, adopt the top version in trunk as the sole parent so that we can see just the _true_ change from the prior version, without all the noise of the "interim" changes.
I even think the user should be prompted to do so, but one step at a time...
Best, Chris On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Monticello to project The
Inbox:
http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version
to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Nice. It is for someone like Bert to review and accept this but this
seems a very useful addition to me!
Motivated by the exercise of preparing to copy Chronology-Core versions
from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category
'morphic ui') -----
defaultExtent
^600@300!
^450@300!Item was added:
- ----- Method: MCVersion>>reparent (in category 'actions') -----
- reparent
"Let aNode be the sole parent of this version"self workingCopy reparent: self!Item was changed: ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic
ui') -----
buttonSpecs
^#(('Refresh' refresh 'refresh the version-list')
^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion)
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this version wouldmake to the image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor of yourworking copy' hasVersion)
(Reparent reparent 'Adopt this version as the soleancestor of your working copy' hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release' hasVersion)
)!
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this versionwould make to the
- image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor ofyour working copy'
- hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release'
- hasVersion))!
Item was added:
- ----- Method: MCVersionInspector>>reparent (in category 'accessing')
- reparent
(self confirm:'Adopt ',self version info name, ' as the soleancestor of your working copy?')
ifTrue: [self version reparent]!Item was added:
- ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
unclassified') -----
- reparent: aNode
"Let aNode be the sole parent of this version"ancestors := Array with: aNode- !
Item was added:
- ----- Method: MCWorkingCopy>>reparent: (in category 'operations')
- reparent: aVersion
"Let aNode be the sole parent of this version"ancestry reparent: aVersion info.self changed.!-- _,,,^..^,,,_ best, Eliot
A not too common but practical use case is that you don't have to start over from scratch when you had prepared a batch of versions depending on each other requiring .mcm files between them, but someone pushed a different version of the same package before you started to upload yours. With this tool, you can just load/merge, reparent and save each version one-by-one instead of filing out and reloading your changes. You still have to do things to "fix it", but it's a lot less tedious with reparent.
So, +1 from me.
Levente
On Tue, 6 Nov 2018, David T. Lewis wrote:
My use case is different.
Package Chronology-Core is part of the trunk update stream. Separate from this, and hosted in a squeaksource.com repository for UTCDateAndTime, I have a sequence of Chronology-Core versions that ends with a version that I would like to be able to submit into the existing trunk stream.
Both streams (Squeak trunk and SS UTCDateAndTime) are rooting in a common version Chronology-Core-cmm.2 of 3 March 2016. Both streams have progressed in parallel, and are (mostly) functionally equivalent.
I was looking for a way to move the squeaksource.com update stream into trunk without disrupting the existing update stream. A possible solution is to re-save the squeaksource.com versions as versions named 'Chronology-Core.UTC-xxx.nn.mcz' rather than 'Chronology-Core-xxx.nn.mcz'.
In order to do this, I loaded individual versions 'Chronology-Core-xxx.nn.mcz' from the squeaksource repository, then saved them as equivalent 'Chronology-Core.UTC-xxx.nn.mcz' versions in a local repository on my PC (that could later be copied to inbox or trunk if the experiment works).
As part of this process, it was necessary for me to load from one repository, then save to another using the '.UTC' naming. In order for this to work, I needed to be able to reparent the new '.UTC' version to its immediate predecessor in the new repository. This retains the '.UTC' naming throughout the new repository version histary, and results in a sequence of 'Chronology-Core.UTC-xxx.nn.mcz' versions in the new repository that is equivalent to the original, but separate from the naming conventions of the Squeak trunk update stream.
This is probably not a common use case ;-)
Dave
On Tue, Nov 06, 2018 at 02:12:19PM -0800, Bert Freudenberg wrote:
I can see that use case, but meddling with history / parentage is not the right way to do it IMHO. (even the "adopt" button is questionable, except in very limited circumstances) It's too easy to lose changes that way - anything that happened in trunk up to this point from when you branched off would be lost (or it would be the responsibility of the developer to make sure this is not the case, which is way too fragile).
The "standard" way to do this is to do a "merge-and-squash" (standard as in, accepted practice in other developer communities, e.g. "git merge --squash").
This is like a merge (meaning it combines changes from both trunk and your line of commits) but throws away all the intermediate commits, "squashing" all the changes into one single merge commit. That means you can commit as much and as often as you like, but when merging it into trunk, it is only seen as one commit.
But let's ask David: what is your use case?
- Bert -
On Tue, Nov 6, 2018 at 10:37 AM Chris Muller asqueaker@gmail.com wrote:
You read my mind! I didn't review or test it, but I was already thinking about this functionality to help us with Inbox submissions as well.
What I would like to propose is that we feel the need to rapid-fire multiple versions into trunk, to do it into Inbox instead, and when we have the final one ready for trunk, adopt the top version in trunk as the sole parent so that we can see just the _true_ change from the prior version, without all the noise of the "interim" changes.
I even think the user should be prompted to do so, but one step at a time...
Best, Chris On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Monticello to project The
Inbox:
http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version
to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Nice. It is for someone like Bert to review and accept this but this
seems a very useful addition to me!
Motivated by the exercise of preparing to copy Chronology-Core versions
from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category
'morphic ui') -----
defaultExtent
^600@300!
^450@300!Item was added:
- ----- Method: MCVersion>>reparent (in category 'actions') -----
- reparent
"Let aNode be the sole parent of this version"self workingCopy reparent: self!Item was changed: ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic
ui') -----
buttonSpecs
^#(('Refresh' refresh 'refresh the version-list')
^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion)
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this version wouldmake to the image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor of yourworking copy' hasVersion)
(Reparent reparent 'Adopt this version as the soleancestor of your working copy' hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release' hasVersion)
)!
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this versionwould make to the
- image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor ofyour working copy'
- hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release'
- hasVersion))!
Item was added:
- ----- Method: MCVersionInspector>>reparent (in category 'accessing')
- reparent
(self confirm:'Adopt ',self version info name, ' as the soleancestor of your working copy?')
ifTrue: [self version reparent]!Item was added:
- ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
unclassified') -----
- reparent: aNode
"Let aNode be the sole parent of this version"ancestors := Array with: aNode- !
Item was added:
- ----- Method: MCWorkingCopy>>reparent: (in category 'operations')
- reparent: aVersion
"Let aNode be the sole parent of this version"ancestry reparent: aVersion info.self changed.!-- _,,,^..^,,,_ best, Eliot
Guys, is there any way in the UI to get the VersionInspector open on a previously-saved version? "Browse" doesn't do it. "History" doesn't do it. Am I missing something?
We all like this feature, but I think Bert raised a good point about the rawness of it, so what would y'all think about if we required that whatever version you want to reparent to *already exists in the ancestry*? In fact, instead of a Button, maybe it should added to the context menu of the ancestors in the "History" view.
Also, please do not change the #defaultExtent to your own personal preference but move toward making it user-settable.
- Chris On Fri, Nov 9, 2018 at 4:11 PM Levente Uzonyi leves@caesar.elte.hu wrote:
A not too common but practical use case is that you don't have to start over from scratch when you had prepared a batch of versions depending on each other requiring .mcm files between them, but someone pushed a different version of the same package before you started to upload yours. With this tool, you can just load/merge, reparent and save each version one-by-one instead of filing out and reloading your changes. You still have to do things to "fix it", but it's a lot less tedious with reparent.
So, +1 from me.
Levente
On Tue, 6 Nov 2018, David T. Lewis wrote:
My use case is different.
Package Chronology-Core is part of the trunk update stream. Separate from this, and hosted in a squeaksource.com repository for UTCDateAndTime, I have a sequence of Chronology-Core versions that ends with a version that I would like to be able to submit into the existing trunk stream.
Both streams (Squeak trunk and SS UTCDateAndTime) are rooting in a common version Chronology-Core-cmm.2 of 3 March 2016. Both streams have progressed in parallel, and are (mostly) functionally equivalent.
I was looking for a way to move the squeaksource.com update stream into trunk without disrupting the existing update stream. A possible solution is to re-save the squeaksource.com versions as versions named 'Chronology-Core.UTC-xxx.nn.mcz' rather than 'Chronology-Core-xxx.nn.mcz'.
In order to do this, I loaded individual versions 'Chronology-Core-xxx.nn.mcz' from the squeaksource repository, then saved them as equivalent 'Chronology-Core.UTC-xxx.nn.mcz' versions in a local repository on my PC (that could later be copied to inbox or trunk if the experiment works).
As part of this process, it was necessary for me to load from one repository, then save to another using the '.UTC' naming. In order for this to work, I needed to be able to reparent the new '.UTC' version to its immediate predecessor in the new repository. This retains the '.UTC' naming throughout the new repository version histary, and results in a sequence of 'Chronology-Core.UTC-xxx.nn.mcz' versions in the new repository that is equivalent to the original, but separate from the naming conventions of the Squeak trunk update stream.
This is probably not a common use case ;-)
Dave
On Tue, Nov 06, 2018 at 02:12:19PM -0800, Bert Freudenberg wrote:
I can see that use case, but meddling with history / parentage is not the right way to do it IMHO. (even the "adopt" button is questionable, except in very limited circumstances) It's too easy to lose changes that way - anything that happened in trunk up to this point from when you branched off would be lost (or it would be the responsibility of the developer to make sure this is not the case, which is way too fragile).
The "standard" way to do this is to do a "merge-and-squash" (standard as in, accepted practice in other developer communities, e.g. "git merge --squash").
This is like a merge (meaning it combines changes from both trunk and your line of commits) but throws away all the intermediate commits, "squashing" all the changes into one single merge commit. That means you can commit as much and as often as you like, but when merging it into trunk, it is only seen as one commit.
But let's ask David: what is your use case?
- Bert -
On Tue, Nov 6, 2018 at 10:37 AM Chris Muller asqueaker@gmail.com wrote:
You read my mind! I didn't review or test it, but I was already thinking about this functionality to help us with Inbox submissions as well.
What I would like to propose is that we feel the need to rapid-fire multiple versions into trunk, to do it into Inbox instead, and when we have the final one ready for trunk, adopt the top version in trunk as the sole parent so that we can see just the _true_ change from the prior version, without all the noise of the "interim" changes.
I even think the user should be prompted to do so, but one step at a time...
Best, Chris On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Monticello to project The
Inbox:
http://source.squeak.org/inbox/Monticello-dtl.685.mcz
==================== Summary ====================
Name: Monticello-dtl.685 Author: dtl Time: 5 November 2018, 10:52:58.748205 pm UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 Ancestors: Monticello-eem.684
MCVersionInspector has an 'Adopt' button to allow the selected version
to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole parent of a working version. Adjust defaultExtent to accomodate the additional button.
Nice. It is for someone like Bert to review and accept this but this
seems a very useful addition to me!
Motivated by the exercise of preparing to copy Chronology-Core versions
from one repository into equivalent Chronology-Core.UTC versions in another repository (possibly trunk). In this scenario, it is helpful to be able to reparent a newly loaded Chronology-Core version from one repository to be the child of the last saved Chronology-Core.UTC version in another. The '.UTC' suffix in this case is intended to branch those versions from the trunk update stream, allowing later merge to trunk with branch history preserved.
=============== Diff against Monticello-eem.684 ===============
Item was changed: ----- Method: MCRepositoryInspector>>defaultExtent (in category
'morphic ui') -----
defaultExtent
^600@300!
^450@300!Item was added:
- ----- Method: MCVersion>>reparent (in category 'actions') -----
- reparent
"Let aNode be the sole parent of this version"self workingCopy reparent: self!Item was changed: ----- Method: MCVersionInspector>>buttonSpecs (in category 'morphic
ui') -----
buttonSpecs
^#(('Refresh' refresh 'refresh the version-list')
^ #(('Refresh' refresh 'refresh the version-list') (Browse browse 'Browse this version' hasVersion)
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this version wouldmake to the image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor of yourworking copy' hasVersion)
(Reparent reparent 'Adopt this version as the soleancestor of your working copy' hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release' hasVersion)
)!
(History history 'Browse the history of this version'hasVersion)
(Changes changes 'Browse the changes this versionwould make to the
- image' hasVersion)
(Load load 'Load this version into the image'hasVersion)
(Merge merge 'Merge this version into the image'hasVersion)
(Adopt adopt 'Adopt this version as an ancestor ofyour working copy'
- hasVersion)
(Copy save 'Copy this version to another repository'hasVersion)
(Diff diff 'Create an equivalent version based on anearlier release'
- hasVersion))!
Item was added:
- ----- Method: MCVersionInspector>>reparent (in category 'accessing')
- reparent
(self confirm:'Adopt ',self version info name, ' as the soleancestor of your working copy?')
ifTrue: [self version reparent]!Item was added:
- ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
unclassified') -----
- reparent: aNode
"Let aNode be the sole parent of this version"ancestors := Array with: aNode- !
Item was added:
- ----- Method: MCWorkingCopy>>reparent: (in category 'operations')
- reparent: aVersion
"Let aNode be the sole parent of this version"ancestry reparent: aVersion info.self changed.!-- _,,,^..^,,,_ best, Eliot
On Fri, Nov 9, 2018 at 4:10 PM Chris Muller asqueaker@gmail.com wrote:
Guys, is there any way in the UI to get the VersionInspector open on a previously-saved version? "Browse" doesn't do it. "History" doesn't do it. Am I missing something?
We all like this feature, but I think Bert raised a good point about the rawness of it, so what would y'all think about if we required that whatever version you want to reparent to *already exists in the ancestry*? In fact, instead of a Button, maybe it should added to the context menu of the ancestors in the "History" view.
Also, please do not change the #defaultExtent to your own personal preference but move toward making it user-settable.
IMO the *right* way to do this is simply to remember the last size when the window was last closed. This was what I added for the debugger and I love it. It's simple and convenient.
- Chris
On Fri, Nov 9, 2018 at 4:11 PM Levente Uzonyi leves@caesar.elte.hu wrote:
A not too common but practical use case is that you don't have to start over from scratch when you had prepared a batch of versions depending on each other requiring .mcm files between them, but someone pushed a different version of the same package before you started to upload yours. With this tool, you can just load/merge, reparent and save each version one-by-one instead of filing out and reloading your changes. You still have to do things to "fix it", but it's a lot less tedious with reparent.
So, +1 from me.
Levente
On Tue, 6 Nov 2018, David T. Lewis wrote:
My use case is different.
Package Chronology-Core is part of the trunk update stream. Separate
from
this, and hosted in a squeaksource.com repository for UTCDateAndTime,
I
have a sequence of Chronology-Core versions that ends with a version
that
I would like to be able to submit into the existing trunk stream.
Both streams (Squeak trunk and SS UTCDateAndTime) are rooting in a
common
version Chronology-Core-cmm.2 of 3 March 2016. Both streams have
progressed
in parallel, and are (mostly) functionally equivalent.
I was looking for a way to move the squeaksource.com update stream into trunk without disrupting the existing update stream. A possible solution is to re-save the squeaksource.com versions as versions named 'Chronology-Core.UTC-xxx.nn.mcz' rather than
'Chronology-Core-xxx.nn.mcz'.
In order to do this, I loaded individual versions
'Chronology-Core-xxx.nn.mcz'
from the squeaksource repository, then saved them as equivalent 'Chronology-Core.UTC-xxx.nn.mcz' versions in a local repository on my
PC
(that could later be copied to inbox or trunk if the experiment works).
As part of this process, it was necessary for me to load from one repository, then save to another using the '.UTC' naming. In order for this to work, I needed to be able to reparent the new '.UTC' version to its immediate predecessor in the new repository. This retains the
'.UTC'
naming throughout the new repository version histary, and results in a sequence of 'Chronology-Core.UTC-xxx.nn.mcz' versions in the new repository that is equivalent to the original, but separate from the naming conventions of the Squeak trunk update stream.
This is probably not a common use case ;-)
Dave
On Tue, Nov 06, 2018 at 02:12:19PM -0800, Bert Freudenberg wrote:
I can see that use case, but meddling with history / parentage is not
the
right way to do it IMHO. (even the "adopt" button is questionable,
except
in very limited circumstances) It's too easy to lose changes that way
anything that happened in trunk up to this point from when you
branched off
would be lost (or it would be the responsibility of the developer to
make
sure this is not the case, which is way too fragile).
The "standard" way to do this is to do a "merge-and-squash" (standard
as
in, accepted practice in other developer communities, e.g. "git merge --squash").
This is like a merge (meaning it combines changes from both trunk and
your
line of commits) but throws away all the intermediate commits,
"squashing"
all the changes into one single merge commit. That means you can
commit as
much and as often as you like, but when merging it into trunk, it is
only
seen as one commit.
But let's ask David: what is your use case?
- Bert -
On Tue, Nov 6, 2018 at 10:37 AM Chris Muller asqueaker@gmail.com
wrote:
You read my mind! I didn't review or test it, but I was already thinking about this functionality to help us with Inbox submissions
as
well.
What I would like to propose is that we feel the need to rapid-fire multiple versions into trunk, to do it into Inbox instead, and when
we
have the final one ready for trunk, adopt the top version in trunk
as
the sole parent so that we can see just the _true_ change from the prior version, without all the noise of the "interim" changes.
I even think the user should be prompted to do so, but one step at a time...
Best, Chris On Mon, Nov 5, 2018 at 10:20 PM Eliot Miranda <
eliot.miranda@gmail.com>
wrote:
Hi David, Hi All, On Mon, Nov 5, 2018 at 7:53 PM commits@source.squeak.org wrote: > > David T. Lewis uploaded a new version of Monticello to project
The
Inbox:
> http://source.squeak.org/inbox/Monticello-dtl.685.mcz > > ==================== Summary ==================== > > Name: Monticello-dtl.685 > Author: dtl > Time: 5 November 2018, 10:52:58.748205 pm > UUID: b31c1c5b-d61a-4810-8f97-5fdcaf062dc8 > Ancestors: Monticello-eem.684 > > MCVersionInspector has an 'Adopt' button to allow the selected
version
to be added to the parent or parents of a working version. Provide a 'Reparent' button to allow a selected version to become the sole
parent of
a working version. Adjust defaultExtent to accomodate the
additional button.
Nice. It is for someone like Bert to review and accept this but
this
seems a very useful addition to me!
> > > Motivated by the exercise of preparing to copy Chronology-Core
versions
from one repository into equivalent Chronology-Core.UTC versions in
another
repository (possibly trunk). In this scenario, it is helpful to be
able to
reparent a newly loaded Chronology-Core version from one repository
to be
the child of the last saved Chronology-Core.UTC version in another.
The
'.UTC' suffix in this case is intended to branch those versions
from the
trunk update stream, allowing later merge to trunk with branch
history
preserved.
> > =============== Diff against Monticello-eem.684 =============== > > Item was changed: > ----- Method: MCRepositoryInspector>>defaultExtent (in category
'morphic ui') -----
> defaultExtent > + ^600@300! > - ^450@300! > > Item was added: > + ----- Method: MCVersion>>reparent (in category 'actions') ----- > + reparent > + "Let aNode be the sole parent of this version" > + self workingCopy reparent: self! > > Item was changed: > ----- Method: MCVersionInspector>>buttonSpecs (in category
'morphic
ui') -----
> buttonSpecs > + ^#( > + ('Refresh' refresh 'refresh the version-list') > - ^ #(('Refresh' refresh 'refresh the version-list') > (Browse browse 'Browse this version' hasVersion) > + (History history 'Browse the history of this
version'
hasVersion)
> + (Changes changes 'Browse the changes this
version would
make to the image' hasVersion)
> + (Load load 'Load this version into the image'
hasVersion)
> + (Merge merge 'Merge this version into the image'
hasVersion)
> + (Adopt adopt 'Adopt this version as an ancestor
of your
working copy' hasVersion)
> + (Reparent reparent 'Adopt this version as the
sole
ancestor of your working copy' hasVersion)
> + (Copy save 'Copy this version to another
repository'
hasVersion)
> + (Diff diff 'Create an equivalent version based
on an
earlier release' hasVersion)
> + )! > - (History history 'Browse the history of this
version'
hasVersion)
> - (Changes changes 'Browse the changes this
version
would make to the
> - image' hasVersion) > - (Load load 'Load this version into the image'
hasVersion)
> - (Merge merge 'Merge this version into the image'
hasVersion)
> - (Adopt adopt 'Adopt this version as an ancestor
of
your working copy'
> - hasVersion) > - (Copy save 'Copy this version to another
repository'
hasVersion)
> - (Diff diff 'Create an equivalent version based
on an
earlier release'
> - hasVersion))! > > Item was added: > + ----- Method: MCVersionInspector>>reparent (in category
'accessing')
> + reparent > + (self confirm:'Adopt ',self version info name, ' as the
sole
ancestor of your working copy?')
> + ifTrue: [self version reparent]! > > Item was added: > + ----- Method: MCWorkingAncestry>>reparent: (in category 'as yet
unclassified') -----
> + reparent: aNode > + "Let aNode be the sole parent of this version" > + ancestors := Array with: aNode > + ! > > Item was added: > + ----- Method: MCWorkingCopy>>reparent: (in category
'operations')
> + reparent: aVersion > + "Let aNode be the sole parent of this version" > + ancestry reparent: aVersion info. > + self changed.! > >
-- _,,,^..^,,,_ best, Eliot
Also, please do not change the #defaultExtent to your own personal preference but move toward making it user-settable.
IMO the *right* way to do this is simply to remember the last size when the window was last closed. This was what I added for the debugger and I love it. It's simple and convenient.
I can appreciate it as a reasonable behavior and an efficient way for the user to "set" their preferred extent for a window, by type.
However, it also brings context-specific resizes of prior windows to future windows. For example, just because I maximize an inspector to do a one-time interrogation of one specific object doesn't mean I want the next inspector to open that large. Sure, I can easily size it back down, but by then it has distracted me from what I was thinking about to have to think about something else. So, I think there can be a benefit to having a simple defaultExtent and sticking with it.
The good news is, since this is Smalltalk, I'm confident we can come up with a simple way offer both strategies, probably even by window type.
Remembering the last also may not be very intuitive from the sense that people don't think of "closing a window" as a way to "configure" something -- usually they just want to close the window. So, it may useful to also an entry to the window menu.
We definitely need to do something, because these vast swaths of useless whitespace covering my background windows drive me nuts! :)
- Chris
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Muller -
Chris Muller -
commits＠source.squeak.org -
David T. Lewis -
Eliot Miranda -
Levente Uzonyi