Hello, Gofer doesn't likes my package naming :( When i use: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'CMakeVMMaker'; load. it loads the CMakeVMMaker-EstebanLorenzano.15 however, if i open the MC repo browser, it clearly shows that most recent version is CMakeVMMaker-Igor.Stasenko.16 (at the moment of writing this message) which means that Gofer package name/version parsing logic are not in sync with MC. Same applies to VMMaker-oscog.. Tried to do: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'VMMaker-oscog.46'; load. and it barks that given version is not found.. which of course not true. Actually i surprised that Gofer simply don't reusing the MC package enumeration logic.. or maybe it does.. but obviously doing it wrong :) -- Best regards, Igor Stasenko AKA sig.
however, Â if i open the MC repo browser, it clearly shows that most recent version is CMakeVMMaker-Igor.Stasenko.16 Â (at the moment of writing this message)
Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch.
Gofer new    url: 'http://squeaksource.com/VMMaker';    package: 'VMMaker-oscog.46';    load.
and it barks that given version is not found.. which of course not true.
'VMMaker-oscar.46' is clearly not a package name, use #version: to refer to a specific version.
Actually i surprised that Gofer simply don't reusing the MC package enumeration logic.. or maybe it does.. but obviously doing it wrong :)
Please study the documentation in the class comment of Gofer. Lukas -- Lukas Renggli www.lukas-renggli.ch
On 20 January 2011 21:36, Lukas Renggli <renggli@gmail.com> wrote:
however, Â if i open the MC repo browser, it clearly shows that most recent version is CMakeVMMaker-Igor.Stasenko.16 Â (at the moment of writing this message)
Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch? Can you provide an example how to tell Gofer to load it?
Gofer new     url: 'http://squeaksource.com/VMMaker';     package: 'VMMaker-oscog.46';     load.
and it barks that given version is not found.. which of course not true.
'VMMaker-oscar.46' is clearly not a package name, use #version: to refer to a specific version.
okay, i doing: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'VMMaker-oscog'; resolved an Array(a GoferResolvedReference name: 'VMMaker-oscog-Igor.Stasenko.47') hmm.. that doesn't looks right, isnt? Because as you said, following the coventions author's name is 'Igor' and the package is on the branch 'Stasenko' And since Gofer prioritizes main branch, the resolved version should be VMMaker-oscog.46 or i again misunderstood?
Actually i surprised that Gofer simply don't reusing the MC package enumeration logic.. or maybe it does.. but obviously doing it wrong :)
Please study the documentation in the class comment of Gofer.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko AKA sig.
Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch? Can you provide an example how to tell Gofer to load it?
There is no such thing as the latest version in Monticello, unless you download all versions and compare the timestamps.
okay, i doing:
Gofer new     url: 'http://squeaksource.com/VMMaker';     package: 'VMMaker-oscog';      resolved
 an Array(a GoferResolvedReference name: 'VMMaker-oscog-Igor.Stasenko.47')
hmm.. that doesn't looks right, isnt? Because as you said, following the coventions author's name is 'Igor' and the package is on the branch 'Stasenko'
Obviously you must have 'VMMaker-oscog-Igor.Stasenko.47' in your package cache. For me I get 'VMMaker-oscog-Igor.Stasenko.43', because there are only two versions of the package 'VMMaker-oscog' in <http://squeaksource.com/VMMaker>: 'VMMaker-oscog-Igor.Stasenko.43' and 'VMMaker-oscog-Igor.Stasenko.38'. Looks as expected. Lukas -- Lukas Renggli www.lukas-renggli.ch
On 20 January 2011 22:52, Lukas Renggli <renggli@gmail.com> wrote:
Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch? Can you provide an example how to tell Gofer to load it?
There is no such thing as the latest version in Monticello, unless you download all versions and compare the timestamps.
why you saying like that? If i open this repo in monticello browser, i can clearly see what is the latest uploaded version. And i sure that MC browser does not downloads all versions from repository. So, why i can't instruct Gofer to load it?
okay, i doing:
Gofer new     url: 'http://squeaksource.com/VMMaker';     package: 'VMMaker-oscog';      resolved
 an Array(a GoferResolvedReference name: 'VMMaker-oscog-Igor.Stasenko.47')
hmm.. that doesn't looks right, isnt? Because as you said, following the coventions author's name is 'Igor' and the package is on the  branch 'Stasenko'
Obviously you must have 'VMMaker-oscog-Igor.Stasenko.47' in your package cache.
yes, i will upload it shortly. And that strange too, since i told to get the latest version from 'http://squeaksource.com/VMMaker', not from cache. But that probably ok.
For me I get 'VMMaker-oscog-Igor.Stasenko.43', because there are only two versions of the package 'VMMaker-oscog' in <http://squeaksource.com/VMMaker>: 'VMMaker-oscog-Igor.Stasenko.43' and 'VMMaker-oscog-Igor.Stasenko.38'. Looks as expected.
humm.. what about rest VMMaker-oscog* versions?
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko AKA sig.
Hi Igor, 2011/1/21 Igor Stasenko <siguctua@gmail.com>:
On 20 January 2011 22:52, Lukas Renggli <renggli@gmail.com> wrote:
Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch? Can you provide an example how to tell Gofer to load it?
There is no such thing as the latest version in Monticello, unless you download all versions and compare the timestamps.
why you saying like that? If i open this repo in monticello browser, i can clearly see what is the latest uploaded version. And i sure that MC browser does not downloads all versions from repository.
I didn't checked the source code but it seems MC repository inspector always sort the package list by version number and when you save a package in the Monticello Browser you can edit the version number and write a lower number, then you cannot concede the first in the list is the latest cronologically. I don't know why the version number is editable though. Hernán
On 21 January 2011 10:16, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Hi Igor,
2011/1/21 Igor Stasenko <siguctua@gmail.com>:
On 20 January 2011 22:52, Lukas Renggli <renggli@gmail.com> wrote:
Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch.
how about retrieving the latest version regardless of branch? Can you provide an example how to tell Gofer to load it?
There is no such thing as the latest version in Monticello, unless you download all versions and compare the timestamps.
why you saying like that? If i open this repo in monticello browser, i can clearly see what is the latest uploaded version. And i sure that MC browser does not downloads all versions from repository.
I didn't checked the source code but it seems MC repository inspector always sort the package list by version number and when you save a package in the Monticello Browser you can edit the version number and write a lower number, then you cannot concede the first in the list is the latest cronologically. I don't know why the version number is editable though.
Okay, i found the solution. Use Installer ! Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker' works well for me and loads correct *latest* version.
Hernán
-- Best regards, Igor Stasenko AKA sig.
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer. The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used... BTW, I made these changes so that they only applied to Metacello's use of Gofer ... Dale
On 21 January 2011 18:48, Dale Henrichs <dhenrich@vmware.com> wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; Â Â Â project: 'VMMaker'; Â Â Â install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used...
BTW, I made these changes so that they only applied to Metacello's use of Gofer ...
good to know
Dale
-- Best regards, Igor Stasenko AKA sig.
So what is the convention because I would like to enforce it. There is no need to have more mess. Stef On Jan 21, 2011, at 6:48 PM, Dale Henrichs wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used...
BTW, I made these changes so that they only applied to Metacello's use of Gofer ...
Dale
On 21 January 2011 20:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
So what is the convention because I would like to enforce it. There is no need to have more mess.
i prefer to have {PackageName}[-{subname}]*-(.*)\.{number}\.mcz where in (.*) could be anything and we don't really should care. And i'm not agree about numbering. Number is userful way to tell that my version is more recent than yours _without_ checking the date of file or even worse, checking the date(s) inside a file.
Stef
On Jan 21, 2011, at 6:48 PM, Dale Henrichs wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; Â Â Â project: 'VMMaker'; Â Â Â install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used...
BTW, I made these changes so that they only applied to Metacello's use of Gofer ...
Dale
-- Best regards, Igor Stasenko AKA sig.
El vie, 21-01-2011 a las 20:50 +0100, Igor Stasenko escribió:
On 21 January 2011 20:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
So what is the convention because I would like to enforce it. There is no need to have more mess.
i prefer to have
{PackageName}[-{subname}]*-(.*)\.{number}\.mcz
where in (.*) could be anything and we don't really should care.
And i'm not agree about numbering. Number is userful way to tell that my version is more recent than yours _without_ checking the date of file or even worse, checking the date(s) inside a file.
Yes we understand, but that only applies to centralized SCM like subversion. In a distributed SCM like git and monticello the number means nothing. e.g. there could be two branches yours and mine, and both have 345 commits in it. Supposing that we don't skip any number and did nothing weird, there would be exactly 690 versions and bot Package-MiguelCoba.345.mcz and Package-IgorStasenko.345.mcz. If you did those 345 versions in one day and I did mines on a year, one for day, the only way to know which one is more "recent" is with timestamps. But the numbers means nothing in distributed SCMs. Cheers
Stef
On Jan 21, 2011, at 6:48 PM, Dale Henrichs wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used...
BTW, I made these changes so that they only applied to Metacello's use of Gofer ...
Dale
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
El vie, 21-01-2011 a las 13:55 -0600, Miguel Cobá escribió:
Yes we understand, but that only applies to centralized SCM like subversion. In a distributed SCM like git and monticello the number means nothing. e.g. there could be two branches yours and mine, and both have 345 commits in it. Supposing that we don't skip any number and did nothing weird, there would be exactly 690 versions and bot Package-MiguelCoba.345.mcz and Package-IgorStasenko.345.mcz. If you did those 345 versions in one day and I did mines on a year, one for day, the only way to know which one is more "recent" is with timestamps. But the numbers means nothing in distributed SCMs.
Cheers
See, Git don't even use a number, it uses the SHA1 of the bytes that were changed in the repository between commits. That is the most unnumbered-sequentially way to mark a commit. For all practical purposes it is a random number. Cheers
On 21 January 2011 20:57, Miguel Cobá <miguel.coba@gmail.com> wrote:
El vie, 21-01-2011 a las 13:55 -0600, Miguel Cobá escribió:
Yes we understand, but that only applies to centralized SCM like subversion. In a distributed SCM like git and monticello the number means nothing. e.g. there could be two branches yours and mine, and both have 345 commits in it. Supposing that we don't skip any number and did nothing weird, there would be exactly 690 versions and bot Package-MiguelCoba.345.mcz and Package-IgorStasenko.345.mcz. If you did those 345 versions in one day and I did mines on a year, one for day, the only way to know which one is more "recent" is with timestamps. But the numbers means nothing in distributed SCMs.
Cheers
See, Git don't even use a number, it uses the SHA1 of the bytes that were changed in the repository between commits. That is the most unnumbered-sequentially way to mark a commit. For all practical purposes it is a random number.
So lets do the same and get rid of numbers. So, name will be PackageName-SHA1.mcz everything else, like author and commit date is in package
Cheers
-- Best regards, Igor Stasenko AKA sig.
El vie, 21-01-2011 a las 21:00 +0100, Igor Stasenko escribió:
So lets do the same and get rid of numbers. So, name will be
PackageName-SHA1.mcz
everything else, like author and commit date is in package
I am for this change, but as I pointed before, it would break things, or more surely, it will be the turning point between Squeak/Pharo, as the same tool couldn't be used to manage the same code. The code will need to be packaged twice, once for squeak, once for pharo. Unless that Squeak also adopt this change, that is very unlikely (well if Duke Nukem Forever has a release date now, then everything is possible :) Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Jan 21, 2011, at 8:50 PM, Igor Stasenko wrote:
On 21 January 2011 20:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
So what is the convention because I would like to enforce it. There is no need to have more mess.
i prefer to have
{PackageName}[-{subname}]*-(.*)\.{number}\.mcz
where in (.*) could be anything and we don't really should care.
And i'm not agree about numbering. Number is userful way to tell that my version is more recent than yours _without_ checking the date of file or even worse, checking the date(s) inside a file.
but you cannot simply since the numbering is local to your repository. I could publish a more recent package with a small number and push it in your repository.
Stef
On Jan 21, 2011, at 6:48 PM, Dale Henrichs wrote:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used...
BTW, I made these changes so that they only applied to Metacello's use of Gofer ...
Dale
-- Best regards, Igor Stasenko AKA sig.
+1
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
This thing of the initial is really upsetting. I know that is old history and that even tools were made (monticello) relying on them (even without specifying an accepted format, creating more confusion) but I think that enough is enough. So, monticello hasn't a format for the filenames of the packages, at least one that avoid problems due to initials, fullnames or whatever string that the user happen to write in their image. For Igor, the problem is that he writes his name as Igor.Stasenko. That chokes monticello and gofer and whatnot. Why don't we use the git way and let the user write two things, an email and a free user name. And then sign the monticello packages with email and in a meta-info inside the mcz (or in the commit info/message) use the full name? What do you think? What it would break with a change like this? Cheers El vie, 21-01-2011 a las 20:40 +0100, Stéphane Ducasse escribió:
+1
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On 21 January 2011 20:48, Miguel Cobá <miguel.coba@gmail.com> wrote:
This thing of the initial is really upsetting.
I know that is old history and that even tools were made (monticello) relying on them (even without specifying an accepted format, creating more confusion) but I think that enough is enough.
So, monticello hasn't a format for the filenames of the packages, at least one that avoid problems due to initials, fullnames or whatever string that the user happen to write in their image.
For Igor, the problem is that he writes his name as Igor.Stasenko. That chokes monticello and gofer and whatnot.
I can tell you more. I am specifically using this name, because: when system asked me to enter initials, it wasn't warned me that my name is wrong or refused to use it and from that point, when something doesn't works because of my initials, this is NOT my fault. This is a fault of those tools, which put too much assumptions about what user could enter into text field when asked. So, lets fix the tools, instead of arguing , what convention should be. There should not be any convention about what i can use as my user name. I can choose to use Egyptian glyphs for initials. And don't force me to follow some scheme if its not necessary.
Why don't we use the git way and let the user write two things, an email and a free user name. And then sign the monticello packages with email and in a meta-info inside the mcz (or in the commit info/message) use the full name?
What do you think? What it would break with a change like this?
Cheers
-- Best regards, Igor Stasenko AKA sig.
I can tell you more. I am specifically using this name, because: when system asked me to enter initials, it wasn't warned me that my name is wrong or refused to use it and from that point, when something doesn't works because of my initials, this is NOT my fault. This is a fault of those tools, which put too much assumptions about what user could enter into text field when asked.
So, lets fix the tools, instead of arguing , what convention should be. There should not be any convention about what i can use as my user name. I can choose to use Egyptian glyphs for initials. And don't force me to follow some scheme if its not necessary.
Yes this is what we started to do with the authorfullname
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
Miguel, A timestamp isn't sufficient in the presence of branching. How do other SCMs identify branches? Dale
El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribió:
On 01/21/2011 08:11 AM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribió:
Okay, i found the solution. Use Installer !
Installer monticello http: 'http://www.squeaksource.com'; project: 'VMMaker'; install: 'CMakeVMMaker'
works well for me and loads correct *latest* version.
That isn't a solution and open again a gratuitous discussion about gofer vs installer.
The point is, in a distributed SCM system, like Monticello is, there isn't a latest version. At least not by the traditional (suversion for example) way of knowing the monotone numeric integer version number. As Lukas said, the only way to know something is latest is to compare timestamps, but not version numbers or commits id. They aren't not intended to be ordered respect to time.
Cheers
Miguel,
A timestamp isn't sufficient in the presence of branching. How do other SCMs identify branches?
I am not an expert, for sure :), but the way Git works AFAICT is by storing in files the SHA1 hash of all the branches heads reachable. That is, if you don't have a pointer to the head of a branch you can't reach the branch, even if the commit is there. Git also stores a history of the last n branches you have visited in case you by accident delete the file containing the pointer to a branch head. So the metadata of git (.git/ folder) has all this information. when rebuilding branches histories (and for merging) git traverses the list of parents of two branches until find two commits with the same id (SHA1) and from there it can do the merge. But as I said, this is metadata and the commit has no way of knowing to which branch it belongs. The commit only know the blog of changes, the author, timestamp and parent(s) commits (if was a merge). This is different that monticello where, appears to me, the commit (.mcz file) encodes the author, branch, version number and package name. In git, there are only blobs that have a defined structure and are named just with the SHA1 hash of the bytes changed in that commit. For more info (very readable) check: http://progit.org/book/ch3-1.html http://progit.org/book/ch9-0.html Cheers
Dale
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On 01/21/2011 01:28 PM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribió:
Miguel,
A timestamp isn't sufficient in the presence of branching. How do other SCMs identify branches?
I am not an expert, for sure :), but the way Git works AFAICT is by storing in files the SHA1 hash of all the branches heads reachable. That is, if you don't have a pointer to the head of a branch you can't reach the branch, even if the commit is there. Git also stores a history of the last n branches you have visited in case you by accident delete the file containing the pointer to a branch head. So the metadata of git (.git/ folder) has all this information. when rebuilding branches histories (and for merging) git traverses the list of parents of two branches until find two commits with the same id (SHA1) and from there it can do the merge. But as I said, this is metadata and the commit has no way of knowing to which branch it belongs. The commit only know the blog of changes, the author, timestamp and parent(s) commits (if was a merge). This is different that monticello where, appears to me, the commit (.mcz file) encodes the author, branch, version number and package name. In git, there are only blobs that have a defined structure and are named just with the SHA1 hash of the bytes changed in that commit.
For more info (very readable) check:
http://progit.org/book/ch3-1.html http://progit.org/book/ch9-0.html
Thanks Miguel, Thats interesting. Actually, the mcz file itself has all of the meta data embedded in it...full history, including UUIDs for each of the versions...the meta information has been encoded into the mcz file name to make it easy for humans and tools to guess what the meta data is (and 99% of the time the mcz file name and meta data match:) Without info encoded in the mcz file name, the tools have to crack open every one of the mcz files in a repository in order to build the real version structure... Presumably a new version of SqueakSource could maintain separate metadata files and then in-image tools could use that metadata to present the mcz files in a coherent manner ... then there would be no need to care what the mcz file was named, the UUID would probably be sufficient... Dale
I think that a stupid numbering like the one we have now is not so bad, you do not want to force the tools to read all the metadata inside the files. I think that we have many more places where we should improve: UI, network layer, Filesystem..... So with a simple fix in the tools to follow a pattern we can get a good impact. So what is the right pattern so that Gofer and Metacello are happy? Stef
On 01/22/2011 12:37 AM, Stéphane Ducasse wrote:
I think that a stupid numbering like the one we have now is not so bad, you do not want to force the tools to read all the metadata inside the files. I think that we have many more places where we should improve: UI, network layer, Filesystem.....
I tend to agree, but...
So with a simple fix in the tools to follow a pattern we can get a good impact. So what is the right pattern so that Gofer and Metacello are happy?
Upon closer examination of the Metacello code, I see that for sorting and comparison operations, Metacello pretty much follows the Gofer sorting scheme (separate methods for wider range of comparison operators)... The departure from Gofer comes in how Metacello matches a package name to a working copy... So in the end if you make Gofer happy you make Metacello happy. Pharo/Gofer parses the package file name looking for the following pattern" packageName, '-', author, '.', branch, '.', counter and Squeak/GemStone parses the package file name with this pattern: packageName, '-', 'author', '.', counter In Squeak/GemStone, the author is allowed to contain '.' and in Pharo a '.' in the author name causes the characters following the '.' to be interpreted as a branch names and in the sorting scheme for Gofer branches have precedence over the counter....which is why Igor's seeing the "wrong sort order in Gofer". In the Squeak/GemStone pattern, branches were indicated by a '.' in the packageName: packageName, '.', branch, '-', author, '.', branch, '.', counter To see examples just look at the old Seaside package names...Nothing about this ever made it into the code, but when I asked Avi way back when .. that is what he told me and I've been using it for years In terms of trying to get Metacello to run on multiple platforms, Pharo naming scheme is a headache, because Squeak/Gemstone allows '.' in author names and Gofer parses them as branch names leading to subtle problems as we've seen Personally, I have never seen a package in the wild that uses the Pharo 'branch' naming scheme...I have just seen problems caused by the 'branch' naming scheme. The RepositoryInspector itself uses the meta information when it sorts so it doesn't use the package name at all and in Igor's case, CMakeVMMaker-EstebanLorenzano.15 is an ancestor of CMakeVMMaker-Igor.Stasenko.16 and shows CMakeVMMaker-Igor.Stasenko.16 as the latest version, which means that the tools are inconsistent... My opinion is that the 'branch' naming scheme just causes problems and isn't in common use so I wouldn't mind seeing it dropped. Without the Pharo-style branch naming scheme a simple-minded sort based on the counter usually matches the actual ancestry... With that said I have seen projects with package naming conventions that don't include author names and don't have counters, so the naming schemes for packages is just a mess...without digging in and using the actual ancestry meta information, we are guaranteed to have inconsistencies no matter what we do... Dale
Ok so I have the impression that we could get rid of branching or use another delimiter. Would it be ok? Lukas? Dale? Stef On Jan 24, 2011, at 7:06 PM, Dale Henrichs wrote:
On 01/22/2011 12:37 AM, Stéphane Ducasse wrote:
I think that a stupid numbering like the one we have now is not so bad, you do not want to force the tools to read all the metadata inside the files. I think that we have many more places where we should improve: UI, network layer, Filesystem.....
I tend to agree, but...
So with a simple fix in the tools to follow a pattern we can get a good impact. So what is the right pattern so that Gofer and Metacello are happy?
Upon closer examination of the Metacello code, I see that for sorting and comparison operations, Metacello pretty much follows the Gofer sorting scheme (separate methods for wider range of comparison operators)... The departure from Gofer comes in how Metacello matches a package name to a working copy...
So in the end if you make Gofer happy you make Metacello happy.
Pharo/Gofer parses the package file name looking for the following pattern"
packageName, '-', author, '.', branch, '.', counter
and Squeak/GemStone parses the package file name with this pattern:
packageName, '-', 'author', '.', counter
In Squeak/GemStone, the author is allowed to contain '.' and in Pharo a '.' in the author name causes the characters following the '.' to be interpreted as a branch names and in the sorting scheme for Gofer branches have precedence over the counter....which is why Igor's seeing the "wrong sort order in Gofer".
In the Squeak/GemStone pattern, branches were indicated by a '.' in the packageName:
packageName, '.', branch, '-', author, '.', branch, '.', counter
To see examples just look at the old Seaside package names...Nothing about this ever made it into the code, but when I asked Avi way back when .. that is what he told me and I've been using it for years
In terms of trying to get Metacello to run on multiple platforms, Pharo naming scheme is a headache, because Squeak/Gemstone allows '.' in author names and Gofer parses them as branch names leading to subtle problems as we've seen
Personally, I have never seen a package in the wild that uses the Pharo 'branch' naming scheme...I have just seen problems caused by the 'branch' naming scheme.
The RepositoryInspector itself uses the meta information when it sorts so it doesn't use the package name at all and in Igor's case, CMakeVMMaker-EstebanLorenzano.15 is an ancestor of CMakeVMMaker-Igor.Stasenko.16 and shows CMakeVMMaker-Igor.Stasenko.16 as the latest version, which means that the tools are inconsistent...
My opinion is that the 'branch' naming scheme just causes problems and isn't in common use so I wouldn't mind seeing it dropped. Without the Pharo-style branch naming scheme a simple-minded sort based on the counter usually matches the actual ancestry...
With that said I have seen projects with package naming conventions that don't include author names and don't have counters, so the naming schemes for packages is just a mess...without digging in and using the actual ancestry meta information, we are guaranteed to have inconsistencies no matter what we do...
Dale
Ok so I have the impression that we could get rid of branching or use another delimiter.
You cannot get rid of branching, this is a central part of version control and extensively used in many large projects. In Seaside we use the following pattern, also see the documentation at http://code.google.com/p/seaside/wiki/PackageNaming: Package = PackageName "-" Author { "." Branch } "." Version However I noticed that other projects (and earlier versions of Seaside) use a different scheme: Package = PackageName { "." Branch } "-" Author "." Version In this case I guess we must support: Package = PackageName { "." Branch } "-" Author { "." Branch } "." Version However, that doesn't change that $. and $- cannot be part of the PackageName or Author. Lukas -- Lukas Renggli www.lukas-renggli.ch
Then an quick/easy fix is to filter out $. from the FullName prompt in the image. Cheers El lun, 24-01-2011 a las 14:16 -0800, Lukas Renggli escribió:
However, that doesn't change that $. and $- cannot be part of the PackageName or Author.
Just $., forget what I said about $-.
Lukas
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
Current Pharo accepts $. as part of the full name. El lun, 24-01-2011 a las 14:22 -0800, Lukas Renggli escribió:
Then an quick/easy fix is to filter out $. from the FullName prompt in the image.
That was one of my first changes to Pharo 0.0001.
Lukas
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On 24 January 2011 14:31, Miguel Cobá <miguel.coba@gmail.com> wrote:
Current Pharo accepts $. as part of the full name.
Then it is broken. Lukas
El lun, 24-01-2011 a las 14:22 -0800, Lukas Renggli escribió:
Then an quick/easy fix is to filter out $. from the FullName prompt in the image.
That was one of my first changes to Pharo 0.0001.
Lukas
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
-- Lukas Renggli www.lukas-renggli.ch
Filtering doesn't help if the package was saved from a Squeak or GemStone image or someone hand edited their package name ... I know that a number of folks don't care about anyone that isn't using the latest version of Pharo, but that is not the case for all developers. Monticello could be a common interchange format for code, but if folks impose incompatible restrictions on package names then we might as well give up on that possibility ... If you want to have a common interchange format, then you need to avoid unilateral changes that cause incompatabilites ... If you don't want to make common code more difficult than it needs to be, then you are headed down the right path ... I apologize in advance for offending anyone and I'll just shut up on this particular issue... Dale On 01/24/2011 02:20 PM, Miguel Cobá wrote:
Then an quick/easy fix is to filter out $. from the FullName prompt in the image.
Cheers
El lun, 24-01-2011 a las 14:16 -0800, Lukas Renggli escribió:
However, that doesn't change that $. and $- cannot be part of the PackageName or Author.
Just $., forget what I said about $-.
Lukas
participants (6)
-
Dale Henrichs -
Hernán Morales Durand -
Igor Stasenko -
Lukas Renggli -
Miguel Cobá -
Stéphane Ducasse