[Seaside-dev] [Seaside] Package conventions & monticello versioning

Sat Feb 5 13:45:01 UTC 2011

Hi Dale,

That's exactly the regression I'm talking about. MC is *supposed* to
consider what you are calling "count" a dotted sequence of tokens. It
could be "1.2.3" or "mybranch.1" and in those cases, MC should
increment the last segment (I believe it would add a new .1 to the end
of the last segment is not numeric) and leave the others as they were.

That's how MC was created. Avi and Colin and I used it that way for
years, and then someone who didn't know it was supposed to work that
way broke the code after Colin stopped maintaining it. When I came
back to Seaside three years ago and noticed it was broken, we pushed a
fix into Pharo and I guess Squeak hasn't picked it up. But it's not
Pharo-specific - it's the way MC always worked, it just wasn't well
documented.

http://code.google.com/p/pharo/issues/detail?id=281

I'd suggest Squeak and Gemstone consider adopting the same fix.

Julian

On Fri, Feb 4, 2011 at 5:54 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
> Julian,
>
> I don't know which dawn of time you are referring to, but the older versions
> of Monticello and the current versions of Squeak and GemStone use the
> convention:
>
>  branch-<initials>.count
>
> where the branch name includes the characters up to the last '-'. The author
> initials are inserted using the current author initials and any pharo-style
> branch information is ignored.
>
> In Squeak4.2, you can create an mcz file of the form:
>
>  package-<initials>.branch.count
>
> but if you try to save a second version of a "branched" packaged, the
> 'branch' is ignored and you are presented with the following pattern:
>
>  package-<initials>.count
>
> Soooo, if anyone is doing cross-platform development you are better off
> staying away from the pharo-specific conventions, because not many
> developers are in the habit of looking at the new name of the package that
> gets generated and the tools are definitely inconsistent.
>
> Dale
>
> On 02/04/2011 08:15 AM, Julian Fitzell wrote:
>>
>> The Squeak one should (have)... it's been built into MC since the dawn
>> of time. As I said, though, it was never really well-known and got
>> broken at some point by someone changing the code. It may be that I
>> only pushed to have the fix included in Pharo and Squeak never
>> followed suit. They should though - it's definitely not
>> Pharo-specific.
>>
>> Julian
>>
>> On Fri, Feb 4, 2011 at 2:58 PM, Dale Henrichs<dhenrich at vmware.com>  wrote:
>>>
>>> Just one minor point ... you are referring to Pharo's branch naming
>>> convention for Monticello ... The Squeak and GemStone tools don't follow
>>> that convention.
>>>
>>> Sigh....
>>>
>>> Dale
>>>
>>> On Feb 4, 2011, at 6:34 AM, Julian Fitzell wrote:
>>>
>>>> Good point, Dale.
>>>>
>>>> The best option is probably to use Monticello's branch naming
>>>> convention:
>>>>
>>>> <package>-<initials>.<branch>.<count>.mcz
>>>>
>>>> The MC UI will maintain all the dotted segments, incrementing the last
>>>> segment (count) on each commit. It got broken for a while, but recent
>>>> version of MC have it fixed again.
>>>>
>>>> Using this pattern means the tools will maintain the branch for you on
>>>> each subsequent commit and the versions will still show up in the
>>>> version list for the package.
>>>>
>>>> Julian
>>>>
>>>> On Fri, Feb 4, 2011 at 1:33 PM, Dale Henrichs<dhenrich at vmware.com>
>>>>  wrote:
>>>>>
>>>>> Avi,
>>>>>
>>>>> I am suspicious about using a '-' to separate the author name and
>>>>> issueXXX .... I don't recall the exact rules that Gofer/Monticello uses in
>>>>> interpreting mcz file names, but I think that using the '-' where you
>>>>> suggest will cause issueXXX to be interpreted as the author name ... also
>>>>> you need to include an integer count of some sort before the .mcz extension
>>>>> or you will get into even more trouble.
>>>>>
>>>>> I have had success over the years using the following pattern:
>>>>>
>>>>>  Seaside-Core.IssueXXX-<initials>.<count>.mcz
>>>>>
>>>>> This pattern will not be inadvertently interpreted as a Seaside-Core
>>>>> package by Gofer/Monticello and is very readable.
>>>>>
>>>>> Dale
>>>>>
>>>>> On Feb 3, 2011, at 10:41 AM, Avi Shefi wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>> Assuming you are working on fixing several issues on the Seaside-Core
>>>>> package, what's the best way to work on issues&  patches using Monticello?
>>>>> The best option I can think of is:
>>>>> 1) do your work on the issue
>>>>> 2) save it to a mcz file named: Seaside-Core-<initials>-issueXXX.mcz
>>>>> 3) reload the original ancestor from which you started
>>>>> 4) keep working on other issues without having the code of the previous
>>>>> fix inside the image
>>>>>
>>>>> This way, if you make multiple changes on the same package you will be
>>>>> able to send each one of them in a different file, without getting the code
>>>>> mixed-up along the fixes you submit.
>>>>>
>>>>> Is this the right way?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Avi.
>>>>>
>>>>> <ATT00001..txt>
>>>>>
>>>>> _______________________________________________
>>>>> seaside-dev mailing list
>>>>> seaside-dev at lists.squeakfoundation.org
>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>
>>>> _______________________________________________
>>>> seaside-dev mailing list
>>>> seaside-dev at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>>> _______________________________________________
>>> seaside-dev mailing list
>>> seaside-dev at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>