Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.52.mcz
On Sun, Mar 20, 2011 at 11:23 AM, Tobias Pape <Das.Linux@gmx.de> wrote:
Am 2011-03-20 um 19:17 schrieb Eliot Miranda:
On Sun, Mar 20, 2011 at 11:15 AM, Tobias Pape <Das.Linux@gmx.de> 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:
So how did Monticello allow me to do that? That's a /bad/ bug.
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.
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
So Long, -Tobias
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)
On 20 March 2011 20:33, Matthew Fulmer <tapplek@gmail.com> 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 <tapplek@gmail.com> 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)
No i'm talking about Metacello configuration, which currently used to 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.
Just for the record. If anyone is having his own monticello repository like me using apache a rule RewriteEngine On RewriteCond %{REQUEST_METHOD} ^PUT RewriteCond %{REQUEST_FILENAME} -f RewriteRule . - [F,L] will prevent overwriting of packages. The full story is at http://norbert.hartl.name/blog/public-monticello-repository Norbert
As demonstrated by the VMMaker team, SqueakSource has a rather serious security vunerability: http://bugs.squeak.org/view.php?id=7617 Below is the dialog that led to this discovery: On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
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:
So how did Monticello allow me to do that? That's a /bad/ bug.
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. <<<<
-- Matthew Fulmer (a.k.a. Tapple)
Am 2011-03-21 um 03:24 schrieb Matthew Fulmer:
As demonstrated by the VMMaker team, SqueakSource has a rather serious security vunerability:
http://bugs.squeak.org/view.php?id=7617
Below is the dialog that led to this discovery:
Note that SqueakSource 2 and 3 are unaffected of this bug. Moreover, find attached a quick fix that is a backport of the conflict handling in SqueakSource 2 to the original SqueakSource. HTH So Long, -Tobias
It's surprising to me that you find this "news". SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad. Loading Squeak code is inherently dangerous. Installing code usually executes "initialize" methods immediately. That could easily wipe your disk, since almost nobody is using the VM's sandbox (AFAIK, only Etoys uses that feature). OTOH this is not much different from installing a Linux package which also executes "install scripts" that potentially could do a lot of danger. But e.g. the trunk repository is not world-writable so there is no immediate risk. It would be a lot safer if we had signed MCZ packages. Or even better, a tamper-proof history (like git). - Bert - On 21.03.2011, at 03:24, Matthew Fulmer wrote:
As demonstrated by the VMMaker team, SqueakSource has a rather serious security vunerability:
http://bugs.squeak.org/view.php?id=7617
Below is the dialog that led to this discovery:
On Sun, Mar 20, 2011 at 11:26:20AM -0700, Eliot Miranda wrote:
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:
So how did Monticello allow me to do that? That's a /bad/ bug.
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. <<<<
-- Matthew Fulmer (a.k.a. Tapple)
On 21 Mar 2011, at 11:20, Bert Freudenberg wrote:
SqueakSource is simply a WebDAV server. All the versioning logic is local, implemented in Monticello, so allowing overwrites is not really SqueakSource's "fault". Besides, even if SqueakSource disallowed overwriting a version (which it probably should) nothing would prevent somebody else to upload a *new* version that did something bad.
Yes versioning/naming is local and distributed, that is a feature. One cannot rely on the name alone. However, it is most certainly a bug that a server happily overwrites existing versions, a version control system should never do that. Your other points a valid, of course. Sven
participants (7)
-
Bert Freudenberg -
Eliot Miranda -
Igor Stasenko -
Matthew Fulmer -
Norbert Hartl -
Sven Van Caekenberghe -
Tobias Pape