The Inbox: Monticello-dtl.685.mcz
Locked
 
|
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.! |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
Hi David, Hi All,
On Mon, Nov 5, 2018 at 7:53 PM <[hidden email]> wrote: David T. Lewis uploaded a new version of Monticello to project The Inbox: Nice. It is for someone like Bert to review and accept this but this seems a very useful addition to me!
_,,,^..^,,,_ best, Eliot |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
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 <[hidden email]> wrote: > > Hi David, Hi All, > On Mon, Nov 5, 2018 at 7:53 PM <[hidden email]> 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 > |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
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 <[hidden email]> wrote: You read my mind! I didn't review or test it, but I was already |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
> 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... |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
In reply to this post by Bert Freudenberg
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 <[hidden email]> 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 <[hidden email]> > > wrote: > > > > > > Hi David, Hi All, > > > On Mon, Nov 5, 2018 at 7:53 PM <[hidden email]> 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 > > > > > > > > |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
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 <[hidden email]> 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 <[hidden email]> >> > wrote: >> > > >> > > Hi David, Hi All, >> > > On Mon, Nov 5, 2018 at 7:53 PM <[hidden email]> 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 >> > > >> > >> > > >> |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> > >> > wrote: > >> > > > >> > > Hi David, Hi All, > >> > > On Mon, Nov 5, 2018 at 7:53 PM <[hidden email]> 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 > >> > > > >> > > >> > > > > >> > |
Re: The Inbox: Monticello-dtl.685.mcz
|
|
On Fri, Nov 9, 2018 at 4:10 PM Chris Muller <[hidden email]> wrote: Guys, is there any way in the UI to get the VersionInspector open on a 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.
_,,,^..^,,,_ 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |