Gofer issue

> 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?

> On 21 January 2011 20:41, Stéphane Ducasse <[hidden email]> 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.
>

>
> 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.

> 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

> 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

> 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
>>
>

>
> 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
>
>
>
>
>

> 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.