Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog.52.mcz ==================== Summary ==================== Name: VMMaker-oscog.52 Author: eem Time: 20 March 2011, 9:31:20 am UUID: 1241a856-8570-4725-a069-a6d3d8a8a222 Ancestors: VMMaker-oscog.51 Fix primitiveFlushCacheByMethod for objects-as-methods. |
Eliot , you overridden my version with same number: ------- Name: VMMaker-oscog.52 Author: IgorStasenko Time: 18 March 2011, 12:45:14 am UUID: a2810aac-4423-6740-b70e-7e821b979cb4 Ancestors: VMMaker-oscog-IgorStasenko.50, VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 Merge with oscog-49-51 & Esteban-50 ------- I feel like you continuously ignoring my requests to merge the code base.. and work together on merged instance of VMMaker. If you don't like this code, just say it. But don't ignore. On 20 March 2011 18:44, <[hidden email]> wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://www.squeaksource.com/VMMaker/VMMaker-oscog.52.mcz > > ==================== Summary ==================== > > Name: VMMaker-oscog.52 > Author: eem > Time: 20 March 2011, 9:31:20 am > UUID: 1241a856-8570-4725-a069-a6d3d8a8a222 > Ancestors: VMMaker-oscog.51 > > Fix primitiveFlushCacheByMethod for objects-as-methods. > > -- Best regards, Igor Stasenko AKA sig. |
Hi Igor, On Sun, Mar 20, 2011 at 10:16 AM, Igor Stasenko <[hidden email]> wrote:
Its not intentional. It's simply a matter of finding time to do the merge. Mariano posted a bug. I fixed just that bug and published. I'm not dissing you. I have very limited time.
|
Am 2011-03-20 um 19:09 schrieb Eliot Miranda: > ------- > Name: VMMaker-oscog.52 > Author: IgorStasenko > Time: 18 March 2011, 12:45:14 am > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 > Ancestors: VMMaker-oscog-IgorStasenko.50, > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 > > Merge with oscog-49-51 & Esteban-50 > ------- > > I feel like you continuously ignoring my requests to merge the code > base.. and work together on merged instance > of VMMaker. > If you don't like this code, just say it. But don't ignore. > > Its not intentional. It's simply a matter of finding time to do the merge. Mariano posted a bug. I fixed just that bug and published. I'm not dissing you. I have very limited time. > Hmm, wouldn't applying the “default” naming scheme prevent such overwrites? That is, now there would be VMMaker-oscog-eem.52 for Elliots version and VMMaker-oscog-IgorStasenko.52 for Igors version. What would prevent us from that? So Long, -Tobias |
On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <[hidden email]> wrote:
I don't see a naming conflict. I've been using VMMaker-oscog.NN since the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This isn't about names, it's about content. Igor is miffed I didn't merge in some changes he made when I published VMMaker-oscog.52, right Igor?
best Eliot
|
Am 2011-03-20 um 19:17 schrieb Eliot Miranda: > > > On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <[hidden email]> wrote: > > Am 2011-03-20 um 19:09 schrieb Eliot Miranda: > > > ------- > > Name: VMMaker-oscog.52 > > Author: IgorStasenko > > Time: 18 March 2011, 12:45:14 am > > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 > > Ancestors: VMMaker-oscog-IgorStasenko.50, > > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 > > > > Merge with oscog-49-51 & Esteban-50 > > ------- > > > > I feel like you continuously ignoring my requests to merge the code > > base.. and work together on merged instance > > of VMMaker. > > If you don't like this code, just say it. But don't ignore. > > > > Its not intentional. It's simply a matter of finding time to do the merge. Mariano posted a bug. I fixed just that bug and published. I'm not dissing you. I have very limited time. > > > > Hmm, wouldn't applying the “default” naming scheme prevent such overwrites? > > That is, now there would be > VMMaker-oscog-eem.52 > for Elliots version and > VMMaker-oscog-IgorStasenko.52 > for Igors version. > What would prevent us from that? > > I don't see a naming conflict. I've been using VMMaker-oscog.NN since the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This isn't about names, it's about content. Igor is miffed I didn't merge in some changes he made when I published VMMaker-oscog.52, right Igor? > No, you—obviously accidentally—overwrote his version of the 18th of March: >>> Name: VMMaker-oscog.52 Author: IgorStasenko Time: 18 March 2011, 12:45:14 am UUID: a2810aac-4423-6740-b70e-7e821b979cb4 Ancestors: VMMaker-oscog-IgorStasenko.50, VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 Merge with oscog-49-51 & Esteban-50 <<<< which has the same file name as yours: >>> Name: VMMaker-oscog.52 Author: eem Time: 20 March 2011, 9:31:20 am UUID: 1241a856-8570-4725-a069-a6d3d8a8a222 Ancestors: VMMaker-oscog.51 Fix primitiveFlushCacheByMethod for objects-as-methods. <<<< Since oscog is, as far as I can see, a kind-of branch of the “default” VM-Maker, I think adding the developer initial/name to the Package name would be in the spirit of monticello idioms. So Long, -Tobias |
On Sun, Mar 20, 2011 at 11:23 AM, Tobias Pape <[hidden email]> wrote:
So how did Monticello allow me to do that? That's a /bad/ bug.
Except that its my branch and I've been using oscog from the start. Igor had no need to use the same name line as me. I don't want to change now. oscog refers to my branch of VMMaker for "open source Cog".
cheers Eliot
|
On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote: > Except that its my branch and I've been using oscog from the start. Igor > had no need to use the same name line as me. I don't want to change now. > oscog refers to my branch of VMMaker for "open source Cog". It's not really open source if nobody else can contribute to that branch. Squeaksource apparently allows versions to be overwritten. I didn't know that either. Maybe that's part of the reason the naming convention has been adopted: Package-author.version The best supported convention for maintaining a branch is to use a different repository. MC is distributed, so packages can be merged between repositories no problem. So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz would be a trunk commit, and http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would be a cog commit. Changing the package name is not really supported; Most MC implementations can't merge between packages (MC1.5 could, but I havn't ported that to any MC that's actually in use) I like seperate repositories better anyway; then you can know if there is a newer version of your branch available just by seeing if VMMaker package is bold in the repo browser; if they are in the same repository, you have to pay attention to the commits -- Matthew Fulmer (a.k.a. Tapple) |
In reply to this post by Eliot Miranda-2
On 20 March 2011 19:17, Eliot Miranda <[hidden email]> wrote: > > > > On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <[hidden email]> wrote: >> >> Am 2011-03-20 um 19:09 schrieb Eliot Miranda: >> >> > ------- >> > Name: VMMaker-oscog.52 >> > Author: IgorStasenko >> > Time: 18 March 2011, 12:45:14 am >> > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 >> > Ancestors: VMMaker-oscog-IgorStasenko.50, >> > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 >> > >> > Merge with oscog-49-51 & Esteban-50 >> > ------- >> > >> > I feel like you continuously ignoring my requests to merge the code >> > base.. and work together on merged instance >> > of VMMaker. >> > If you don't like this code, just say it. But don't ignore. >> > >> > Its not intentional. It's simply a matter of finding time to do the merge. Mariano posted a bug. I fixed just that bug and published. I'm not dissing you. I have very limited time. >> > >> >> Hmm, wouldn't applying the “default” naming scheme prevent such overwrites? >> >> That is, now there would be >> VMMaker-oscog-eem.52 >> for Elliots version and >> VMMaker-oscog-IgorStasenko.52 >> for Igors version. >> What would prevent us from that? > > I don't see a naming conflict. I've been using VMMaker-oscog.NN since the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This isn't about names, it's about content. Igor is miffed I didn't merge in some changes he made when I published VMMaker-oscog.52, right Igor? actully publishing my version under VMMaker-oscog.NN was attempt to force you to stumble upon it and merge before you will release next version. Instead it has absolutely different effect, worst that can be imagined :) >From now on, i will always use VMMaker-oscog-IgorStasenko.NNN scheme. -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Tapple Gao
On 20 March 2011 20:33, Matthew Fulmer <[hidden email]> wrote: > > On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote: >> Except that its my branch and I've been using oscog from the start. Igor >> had no need to use the same name line as me. I don't want to change now. >> oscog refers to my branch of VMMaker for "open source Cog". > > It's not really open source if nobody else can contribute to > that branch. Squeaksource apparently allows versions to be > overwritten. I didn't know that either. Maybe that's part of the > reason the naming convention has been adopted: > Package-author.version > > The best supported convention for maintaining a branch is to use > a different repository. MC is distributed, so packages can be > merged between repositories no problem. > > So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz > would be a trunk commit, and > http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would > be a cog commit. > > Changing the package name is not really supported; Most MC > implementations can't merge between packages (MC1.5 could, but I > havn't ported that to any MC that's actually in use) > > I like seperate repositories better anyway; then you can know if > there is a newer version of your branch available just by seeing > if VMMaker package is bold in the repo browser; if they are in > the same repository, you have to pay attention to the commits > I agree that having different repos could simplify things. Except things which will otherwise complicate them: - publishing new VMMaker version sends nice email to mailing list - configuration(s) to automatically load VMMaker with all dependencies relying on having VMMaker package at certain known location, not at multiple ones. So, lets keep pushing to SqS/VMMaker but use different naming scheme. > -- > Matthew Fulmer (a.k.a. Tapple) > -- Best regards, Igor Stasenko AKA sig. |
On Sun, Mar 20, 2011 at 10:02:05PM +0100, Igor Stasenko wrote: > I agree that having different repos could simplify things. > Except things which will otherwise complicate them: > - publishing new VMMaker version sends nice email to mailing list This is just a setting in SqueakSource that can be set for any repository. Just have both repositories notify this list > - configuration(s) to automatically load VMMaker with all > dependencies relying on having VMMaker package at certain known > location, > not at multiple ones. If you want to load a working VMMaker, you aren't going to mix stuff from cog and stable VMMaker repositories without a manual merge first. And if you are talking about .mcm files, they support multiple repositories, as long as package names are not duplicated (like, if there are two different packages named VMMaker-oscog.52 in each repo, it's undefined which one mcm will load) -- Matthew Fulmer (a.k.a. Tapple) |
On 21 March 2011 02:16, Matthew Fulmer <[hidden email]> wrote: > On Sun, Mar 20, 2011 at 10:02:05PM +0100, Igor Stasenko wrote: >> I agree that having different repos could simplify things. >> Except things which will otherwise complicate them: >> - publishing new VMMaker version sends nice email to mailing list > > This is just a setting in SqueakSource that can be set for any > repository. Just have both repositories notify this list > >> - configuration(s) to automatically load VMMaker with all >> dependencies relying on having VMMaker package at certain known >> location, >> not at multiple ones. > > If you want to load a working VMMaker, you aren't going to mix > stuff from cog and stable VMMaker repositories without a manual > merge first. And if you are talking about .mcm files, they > support multiple repositories, as long as package names are not > duplicated (like, if there are two different packages named > VMMaker-oscog.52 in each repo, it's undefined which one mcm will > load) > load VMMaker. But you are right, i still manually control each update, so i can always change the location & packages which should be loaded for new version(s). > -- > Matthew Fulmer (a.k.a. Tapple) > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Tapple Gao
On Sun, 20 Mar 2011, Matthew Fulmer wrote: > > On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote: >> Except that its my branch and I've been using oscog from the start. Igor >> had no need to use the same name line as me. I don't want to change now. >> oscog refers to my branch of VMMaker for "open source Cog". > > It's not really open source if nobody else can contribute to > that branch. Squeaksource apparently allows versions to be Open source ~= open repository. (It's funny that squeaksource.com has lots of repositories with MIT license and "No access" setting.) > overwritten. I didn't know that either. Maybe that's part of the > reason the naming convention has been adopted: > Package-author.version > > The best supported convention for maintaining a branch is to use > a different repository. MC is distributed, so packages can be > merged between repositories no problem. If the idea is to merge the two branches, then it's unnecessary. > > So http://squeaksource.com/VMMaker/VMMaker-IgorStasenko.53.mcz > would be a trunk commit, and > http://squeaksource.com/OSCog/VMMaker-IgorStasenko.54.mcz would > be a cog commit. > > Changing the package name is not really supported; Most MC > implementations can't merge between packages (MC1.5 could, but I Yeah, that's pretty annoying. > havn't ported that to any MC that's actually in use) > > I like seperate repositories better anyway; then you can know if > there is a newer version of your branch available just by seeing > if VMMaker package is bold in the repo browser; if they are in > the same repository, you have to pay attention to the commits If you save directly to the repository, then MC will warn you if there's a newer version there, if you copy your package from another repository, then it won't. Levente > > -- > Matthew Fulmer (a.k.a. Tapple) > |
In reply to this post by Igor Stasenko
Part of the work recently completed on Monticello is the reification of the name into a MCVersionName. It has accessors that operate on a string-structure of: [package name]-[author].version I don't know off the top of my head all what impacts having two dashes in the "author" (or, is that second token part of the package name?)... I hope you will consider an alternative that stays with the standard MC naming structure. - Chris On Sun, Mar 20, 2011 at 3:57 PM, Igor Stasenko <[hidden email]> wrote: > > On 20 March 2011 19:17, Eliot Miranda <[hidden email]> wrote: >> >> >> >> On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <[hidden email]> wrote: >>> >>> Am 2011-03-20 um 19:09 schrieb Eliot Miranda: >>> >>> > ------- >>> > Name: VMMaker-oscog.52 >>> > Author: IgorStasenko >>> > Time: 18 March 2011, 12:45:14 am >>> > UUID: a2810aac-4423-6740-b70e-7e821b979cb4 >>> > Ancestors: VMMaker-oscog-IgorStasenko.50, >>> > VMMaker-oscog-EstebanLorenzano.50, VMMaker-oscog.51 >>> > >>> > Merge with oscog-49-51 & Esteban-50 >>> > ------- >>> > >>> > I feel like you continuously ignoring my requests to merge the code >>> > base.. and work together on merged instance >>> > of VMMaker. >>> > If you don't like this code, just say it. But don't ignore. >>> > >>> > Its not intentional. It's simply a matter of finding time to do the merge. Mariano posted a bug. I fixed just that bug and published. I'm not dissing you. I have very limited time. >>> > >>> >>> Hmm, wouldn't applying the “default” naming scheme prevent such overwrites? >>> >>> That is, now there would be >>> VMMaker-oscog-eem.52 >>> for Elliots version and >>> VMMaker-oscog-IgorStasenko.52 >>> for Igors version. >>> What would prevent us from that? >> >> I don't see a naming conflict. I've been using VMMaker-oscog.NN since the beginning and Igor has been using VMMaker-oscog-IgorStasenko.NN. This isn't about names, it's about content. Igor is miffed I didn't merge in some changes he made when I published VMMaker-oscog.52, right Igor? > > actully publishing my version under VMMaker-oscog.NN was attempt to > force you to stumble upon it and merge before you will release next > version. > Instead it has absolutely different effect, worst that can be imagined :) > > >From now on, i will always use > VMMaker-oscog-IgorStasenko.NNN scheme. > > > -- > Best regards, > Igor Stasenko AKA sig. > |
Free forum by Nabble | Edit this page |