[Seaside] Package conventions & monticello versioning

>
> 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.
>
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>

> 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> 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<[hidden email]>  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<[hidden email]>  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
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> 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<[hidden email]>  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<[hidden email]>
>>>>  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
>>>>> [hidden email]
>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>
>>>> _______________________________________________
>>>> seaside-dev mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>

> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>  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
>>>>>> [hidden email]
>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>
>>>>> _______________________________________________
>>>>> seaside-dev mailing list
>>>>> [hidden email]
>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>
>>>> _______________________________________________
>>>> seaside-dev mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>>

> Julian,
>
> When I first started porting Seaside GemStone to GemStone I asked Avi, what naming convention to use and I did not get the spiel that you have just given. Also, I've never actually seen the naming convention that you mention in the wild ... the old seaside packages don't follow that naming convention. It would have been nice that the naming conventions had been documented and enforced because over the years I have seen a wildly varying number of conventions used.
>
> In the end though isn't it true that Monticello really doesn't care what the name of the file is? Monticello stores all of the branching and ancestral information in it's meta data and the name of the file has no semantic meaning whatsoever.
>
> Finally, from a practical perspective have you actually tried to use your "proposed"  naming convention in a real project?
>
> I have just spent a few minutes experimenting with the Pharo tools using your "proposed" branch naming convention and it doesn't take long to recognize that the tools do not support this model very well - at all.
>
> I suggest that you actually spend some time trying to use this convention in a real project before suggesting that Squeak and GemStone adopt the convention. I will wait until I know how big a job I am faced with in converting the GemStone tool set to support the new model ... that work has not yet been done in Pharo, yet.
>
> As I mention in my original response, in the projects that I have been working on for several years now, where I do a lot of branching, I have found that the following pattern works _very_ well with all of the existing toolset on all platforms:
>
>  packageName.branch-initials.count.mcz
>
> Dale
>
> On Feb 5, 2011, at 5:45 AM, Julian Fitzell wrote:
>
>> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>>  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
>>>>>>> [hidden email]
>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> seaside-dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>
>>>>> _______________________________________________
>>>>> seaside-dev mailing list
>>>>> [hidden email]
>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>
>>>> _______________________________________________
>>>> seaside-dev mailing list
>>>> [hidden email]
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>>>
>
>

> Ergh... sorry Dale. You are absolutely, totally, and in all other ways correct.
>
> We *have* been using the convention I was just describing in Seaside
> for the past few years (and its the one I pushed a fix^H^H^Hhack into
> Pharo for) but I just went and checked and it is *not* the convention
> we were originally using. Obviously I got a wire crossed either while
> trying to create a branch in the first place or while fixing the bug
> in Pharo and it has remain crossed in my mind since (reinforced by the
> fact that the other form now works in Pharo :) ).
>
> What you describe below (packageName.branch-initials.count.mcz) is the
> format that should be supported and the tools do currently seem to
> treat them as the correct package and increment the count properly.
> I'm not sure if I'm happy with the current UI showing branches as
> separate left-column-entries when browsing a repository (very annoying
> with even a small number of branches in a project with lots of
> packages), but that's a minor issue.
>
> So my advice to Avi (Shefi, that is) is still be the same, but using
> the correct naming convention:
>
> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>
> And regarding the other format, should I file an issue with Pharo to
> back out the change from Issue 281?
>
> Julian
>
> On Sat, Feb 5, 2011 at 5:36 PM, Dale Henrichs <[hidden email]> wrote:
>> Julian,
>>
>> When I first started porting Seaside GemStone to GemStone I asked Avi, what naming convention to use and I did not get the spiel that you have just given. Also, I've never actually seen the naming convention that you mention in the wild ... the old seaside packages don't follow that naming convention. It would have been nice that the naming conventions had been documented and enforced because over the years I have seen a wildly varying number of conventions used.
>>
>> In the end though isn't it true that Monticello really doesn't care what the name of the file is? Monticello stores all of the branching and ancestral information in it's meta data and the name of the file has no semantic meaning whatsoever.
>>
>> Finally, from a practical perspective have you actually tried to use your "proposed"  naming convention in a real project?
>>
>> I have just spent a few minutes experimenting with the Pharo tools using your "proposed" branch naming convention and it doesn't take long to recognize that the tools do not support this model very well - at all.
>>
>> I suggest that you actually spend some time trying to use this convention in a real project before suggesting that Squeak and GemStone adopt the convention. I will wait until I know how big a job I am faced with in converting the GemStone tool set to support the new model ... that work has not yet been done in Pharo, yet.
>>
>> As I mention in my original response, in the projects that I have been working on for several years now, where I do a lot of branching, I have found that the following pattern works _very_ well with all of the existing toolset on all platforms:
>>
>>  packageName.branch-initials.count.mcz
>>
>> Dale
>>
>> On Feb 5, 2011, at 5:45 AM, Julian Fitzell wrote:
>>
>>> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>>>  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
>>>>>>>> [hidden email]
>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seaside-dev mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> seaside-dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>
>>>>> _______________________________________________
>>>>> seaside-dev mailing list
>>>>> [hidden email]
>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>
>>>>
>>
>>

> Julian,
>
> I appreciate the apology:)
>
> I have been mystified about this naming convention ever since I first saw it, so I'm glad to put it down to a simple mistake and crossed wires ... I've certainly had my share of mis-rememberings and crossing wires so I fully understand.
>
> I agree that this is the naming convention that is consistent with the current tool sets on all three platforms:
>
>  <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>
> I also agree that the UI could be improved in the way that it handles branches, I've monkeyed around a bit with the GemTools for Monticello, but haven't come up with a better solution ...
>
> An issue to back out the UI changes is a good idea ... also note that the sorting algorithm in Gofer which is based on the wrong convention needs an Issue report as well... as far as I know, these are the only two places to which the wrong naming convention has propagated.
>
> Dale
>
> On Feb 5, 2011, at 10:23 AM, Julian Fitzell wrote:
>
>> Ergh... sorry Dale. You are absolutely, totally, and in all other ways correct.
>>
>> We *have* been using the convention I was just describing in Seaside
>> for the past few years (and its the one I pushed a fix^H^H^Hhack into
>> Pharo for) but I just went and checked and it is *not* the convention
>> we were originally using. Obviously I got a wire crossed either while
>> trying to create a branch in the first place or while fixing the bug
>> in Pharo and it has remain crossed in my mind since (reinforced by the
>> fact that the other form now works in Pharo :) ).
>>
>> What you describe below (packageName.branch-initials.count.mcz) is the
>> format that should be supported and the tools do currently seem to
>> treat them as the correct package and increment the count properly.
>> I'm not sure if I'm happy with the current UI showing branches as
>> separate left-column-entries when browsing a repository (very annoying
>> with even a small number of branches in a project with lots of
>> packages), but that's a minor issue.
>>
>> So my advice to Avi (Shefi, that is) is still be the same, but using
>> the correct naming convention:
>>
>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>
>> And regarding the other format, should I file an issue with Pharo to
>> back out the change from Issue 281?
>>
>> Julian
>>
>> On Sat, Feb 5, 2011 at 5:36 PM, Dale Henrichs <[hidden email]> wrote:
>>> Julian,
>>>
>>> When I first started porting Seaside GemStone to GemStone I asked Avi, what naming convention to use and I did not get the spiel that you have just given. Also, I've never actually seen the naming convention that you mention in the wild ... the old seaside packages don't follow that naming convention. It would have been nice that the naming conventions had been documented and enforced because over the years I have seen a wildly varying number of conventions used.
>>>
>>> In the end though isn't it true that Monticello really doesn't care what the name of the file is? Monticello stores all of the branching and ancestral information in it's meta data and the name of the file has no semantic meaning whatsoever.
>>>
>>> Finally, from a practical perspective have you actually tried to use your "proposed"  naming convention in a real project?
>>>
>>> I have just spent a few minutes experimenting with the Pharo tools using your "proposed" branch naming convention and it doesn't take long to recognize that the tools do not support this model very well - at all.
>>>
>>> I suggest that you actually spend some time trying to use this convention in a real project before suggesting that Squeak and GemStone adopt the convention. I will wait until I know how big a job I am faced with in converting the GemStone tool set to support the new model ... that work has not yet been done in Pharo, yet.
>>>
>>> As I mention in my original response, in the projects that I have been working on for several years now, where I do a lot of branching, I have found that the following pattern works _very_ well with all of the existing toolset on all platforms:
>>>
>>>  packageName.branch-initials.count.mcz
>>>
>>> Dale
>>>
>>> On Feb 5, 2011, at 5:45 AM, Julian Fitzell wrote:
>>>
>>>> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>>>>  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
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> seaside-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seaside-dev mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> seaside-dev mailing list
>>>>>> [hidden email]
>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>
>>>>>
>>>
>>>
>
>

> Here's an issue for Pharo: http://code.google.com/p/pharo/issues/detail?id=3660
>
> Can you handle a report for Gofer? I'm not sure which sorting
> algorithm you mean...
>
> Julian
>
> On Sat, Feb 5, 2011 at 7:02 PM, Dale Henrichs <[hidden email]> wrote:
>> Julian,
>>
>> I appreciate the apology:)
>>
>> I have been mystified about this naming convention ever since I first saw it, so I'm glad to put it down to a simple mistake and crossed wires ... I've certainly had my share of mis-rememberings and crossing wires so I fully understand.
>>
>> I agree that this is the naming convention that is consistent with the current tool sets on all three platforms:
>>
>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>
>> I also agree that the UI could be improved in the way that it handles branches, I've monkeyed around a bit with the GemTools for Monticello, but haven't come up with a better solution ...
>>
>> An issue to back out the UI changes is a good idea ... also note that the sorting algorithm in Gofer which is based on the wrong convention needs an Issue report as well... as far as I know, these are the only two places to which the wrong naming convention has propagated.
>>
>> Dale
>>
>> On Feb 5, 2011, at 10:23 AM, Julian Fitzell wrote:
>>
>>> Ergh... sorry Dale. You are absolutely, totally, and in all other ways correct.
>>>
>>> We *have* been using the convention I was just describing in Seaside
>>> for the past few years (and its the one I pushed a fix^H^H^Hhack into
>>> Pharo for) but I just went and checked and it is *not* the convention
>>> we were originally using. Obviously I got a wire crossed either while
>>> trying to create a branch in the first place or while fixing the bug
>>> in Pharo and it has remain crossed in my mind since (reinforced by the
>>> fact that the other form now works in Pharo :) ).
>>>
>>> What you describe below (packageName.branch-initials.count.mcz) is the
>>> format that should be supported and the tools do currently seem to
>>> treat them as the correct package and increment the count properly.
>>> I'm not sure if I'm happy with the current UI showing branches as
>>> separate left-column-entries when browsing a repository (very annoying
>>> with even a small number of branches in a project with lots of
>>> packages), but that's a minor issue.
>>>
>>> So my advice to Avi (Shefi, that is) is still be the same, but using
>>> the correct naming convention:
>>>
>>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>>
>>> And regarding the other format, should I file an issue with Pharo to
>>> back out the change from Issue 281?
>>>
>>> Julian
>>>
>>> On Sat, Feb 5, 2011 at 5:36 PM, Dale Henrichs <[hidden email]> wrote:
>>>> Julian,
>>>>
>>>> When I first started porting Seaside GemStone to GemStone I asked Avi, what naming convention to use and I did not get the spiel that you have just given. Also, I've never actually seen the naming convention that you mention in the wild ... the old seaside packages don't follow that naming convention. It would have been nice that the naming conventions had been documented and enforced because over the years I have seen a wildly varying number of conventions used.
>>>>
>>>> In the end though isn't it true that Monticello really doesn't care what the name of the file is? Monticello stores all of the branching and ancestral information in it's meta data and the name of the file has no semantic meaning whatsoever.
>>>>
>>>> Finally, from a practical perspective have you actually tried to use your "proposed"  naming convention in a real project?
>>>>
>>>> I have just spent a few minutes experimenting with the Pharo tools using your "proposed" branch naming convention and it doesn't take long to recognize that the tools do not support this model very well - at all.
>>>>
>>>> I suggest that you actually spend some time trying to use this convention in a real project before suggesting that Squeak and GemStone adopt the convention. I will wait until I know how big a job I am faced with in converting the GemStone tool set to support the new model ... that work has not yet been done in Pharo, yet.
>>>>
>>>> As I mention in my original response, in the projects that I have been working on for several years now, where I do a lot of branching, I have found that the following pattern works _very_ well with all of the existing toolset on all platforms:
>>>>
>>>> packageName.branch-initials.count.mcz
>>>>
>>>> Dale
>>>>
>>>> On Feb 5, 2011, at 5:45 AM, Julian Fitzell wrote:
>>>>
>>>>> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> seaside-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> seaside-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> seaside-dev mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

> Will do...
>
> Thanks,
>
> Dale
>
> On Feb 5, 2011, at 11:21 AM, Julian Fitzell wrote:
>
>> Here's an issue for Pharo: http://code.google.com/p/pharo/issues/detail?id=3660
>>
>> Can you handle a report for Gofer? I'm not sure which sorting
>> algorithm you mean...
>>
>> Julian
>>
>> On Sat, Feb 5, 2011 at 7:02 PM, Dale Henrichs <[hidden email]> wrote:
>>> Julian,
>>>
>>> I appreciate the apology:)
>>>
>>> I have been mystified about this naming convention ever since I first saw it, so I'm glad to put it down to a simple mistake and crossed wires ... I've certainly had my share of mis-rememberings and crossing wires so I fully understand.
>>>
>>> I agree that this is the naming convention that is consistent with the current tool sets on all three platforms:
>>>
>>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>>
>>> I also agree that the UI could be improved in the way that it handles branches, I've monkeyed around a bit with the GemTools for Monticello, but haven't come up with a better solution ...
>>>
>>> An issue to back out the UI changes is a good idea ... also note that the sorting algorithm in Gofer which is based on the wrong convention needs an Issue report as well... as far as I know, these are the only two places to which the wrong naming convention has propagated.
>>>
>>> Dale
>>>
>>> On Feb 5, 2011, at 10:23 AM, Julian Fitzell wrote:
>>>
>>>> Ergh... sorry Dale. You are absolutely, totally, and in all other ways correct.
>>>>
>>>> We *have* been using the convention I was just describing in Seaside
>>>> for the past few years (and its the one I pushed a fix^H^H^Hhack into
>>>> Pharo for) but I just went and checked and it is *not* the convention
>>>> we were originally using. Obviously I got a wire crossed either while
>>>> trying to create a branch in the first place or while fixing the bug
>>>> in Pharo and it has remain crossed in my mind since (reinforced by the
>>>> fact that the other form now works in Pharo :) ).
>>>>
>>>> What you describe below (packageName.branch-initials.count.mcz) is the
>>>> format that should be supported and the tools do currently seem to
>>>> treat them as the correct package and increment the count properly.
>>>> I'm not sure if I'm happy with the current UI showing branches as
>>>> separate left-column-entries when browsing a repository (very annoying
>>>> with even a small number of branches in a project with lots of
>>>> packages), but that's a minor issue.
>>>>
>>>> So my advice to Avi (Shefi, that is) is still be the same, but using
>>>> the correct naming convention:
>>>>
>>>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>>>
>>>> And regarding the other format, should I file an issue with Pharo to
>>>> back out the change from Issue 281?
>>>>
>>>> Julian
>>>>
>>>> On Sat, Feb 5, 2011 at 5:36 PM, Dale Henrichs <[hidden email]> wrote:
>>>>> Julian,
>>>>>
>>>>> When I first started porting Seaside GemStone to GemStone I asked Avi, what naming convention to use and I did not get the spiel that you have just given. Also, I've never actually seen the naming convention that you mention in the wild ... the old seaside packages don't follow that naming convention. It would have been nice that the naming conventions had been documented and enforced because over the years I have seen a wildly varying number of conventions used.
>>>>>
>>>>> In the end though isn't it true that Monticello really doesn't care what the name of the file is? Monticello stores all of the branching and ancestral information in it's meta data and the name of the file has no semantic meaning whatsoever.
>>>>>
>>>>> Finally, from a practical perspective have you actually tried to use your "proposed"  naming convention in a real project?
>>>>>
>>>>> I have just spent a few minutes experimenting with the Pharo tools using your "proposed" branch naming convention and it doesn't take long to recognize that the tools do not support this model very well - at all.
>>>>>
>>>>> I suggest that you actually spend some time trying to use this convention in a real project before suggesting that Squeak and GemStone adopt the convention. I will wait until I know how big a job I am faced with in converting the GemStone tool set to support the new model ... that work has not yet been done in Pharo, yet.
>>>>>
>>>>> As I mention in my original response, in the projects that I have been working on for several years now, where I do a lot of branching, I have found that the following pattern works _very_ well with all of the existing toolset on all platforms:
>>>>>
>>>>> packageName.branch-initials.count.mcz
>>>>>
>>>>> Dale
>>>>>
>>>>> On Feb 5, 2011, at 5:45 AM, Julian Fitzell wrote:
>>>>>
>>>>>> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>>>>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> seaside-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> seaside-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> seaside-dev mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> I guess we then have to adapt the package naming conventions on the wiki too?
>
> And yes, I think Gofer follows and tests these (wrong) conventions.
>
> Lukas
>
> On 5 February 2011 20:24, Dale Henrichs <[hidden email]> wrote:
>> Will do...
>>
>> Thanks,
>>
>> Dale
>>
>> On Feb 5, 2011, at 11:21 AM, Julian Fitzell wrote:
>>
>>> Here's an issue for Pharo: http://code.google.com/p/pharo/issues/detail?id=3660
>>>
>>> Can you handle a report for Gofer? I'm not sure which sorting
>>> algorithm you mean...
>>>
>>> Julian
>>>
>>> On Sat, Feb 5, 2011 at 7:02 PM, Dale Henrichs <[hidden email]> wrote:
>>>> Julian,
>>>>
>>>> I appreciate the apology:)
>>>>
>>>> I have been mystified about this naming convention ever since I first saw it, so I'm glad to put it down to a simple mistake and crossed wires ... I've certainly had my share of mis-rememberings and crossing wires so I fully understand.
>>>>
>>>> I agree that this is the naming convention that is consistent with the current tool sets on all three platforms:
>>>>
>>>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>>>
>>>> I also agree that the UI could be improved in the way that it handles branches, I've monkeyed around a bit with the GemTools for Monticello, but haven't come up with a better solution ...
>>>>
>>>> An issue to back out the UI changes is a good idea ... also note that the sorting algorithm in Gofer which is based on the wrong convention needs an Issue report as well... as far as I know, these are the only two places to which the wrong naming convention has propagated.
>>>>
>>>> Dale
>>>>
>>>> On Feb 5, 2011, at 10:23 AM, Julian Fitzell wrote:
>>>>
>>>>> Ergh... sorry Dale. You are absolutely, totally, and in all other ways correct.
>>>>>
>>>>> We *have* been using the convention I was just describing in Seaside
>>>>> for the past few years (and its the one I pushed a fix^H^H^Hhack into
>>>>> Pharo for) but I just went and checked and it is *not* the convention
>>>>> we were originally using. Obviously I got a wire crossed either while
>>>>> trying to create a branch in the first place or while fixing the bug
>>>>> in Pharo and it has remain crossed in my mind since (reinforced by the
>>>>> fact that the other form now works in Pharo :) ).
>>>>>
>>>>> What you describe below (packageName.branch-initials.count.mcz) is the
>>>>> format that should be supported and the tools do currently seem to
>>>>> treat them as the correct package and increment the count properly.
>>>>> I'm not sure if I'm happy with the current UI showing branches as
>>>>> separate left-column-entries when browsing a repository (very annoying
>>>>> with even a small number of branches in a project with lots of
>>>>> packages), but that's a minor issue.
>>>>>
>>>>> So my advice to Avi (Shefi, that is) is still be the same, but using
>>>>> the correct naming convention:
>>>>>
>>>>> <hyphenated-package-name>.<dotted.branch.tag>-<initials>.<count>.mcz
>>>>>
>>>>> And regarding the other format, should I file an issue with Pharo to
>>>>> back out the change from Issue 281?
>>>>>
>>>>> Julian
>>>>>
>>>>> On Sat, Feb 5, 2011 at 5:36 PM, Dale Henrichs <[hidden email]> wrote:
>>>>>> Julian,
>>>>>>
>>>>>> When I first started porting Seaside GemStone to GemStone I asked Avi, what naming convention to use and I did not get the spiel that you have just given. Also, I've never actually seen the naming convention that you mention in the wild ... the old seaside packages don't follow that naming convention. It would have been nice that the naming conventions had been documented and enforced because over the years I have seen a wildly varying number of conventions used.
>>>>>>
>>>>>> In the end though isn't it true that Monticello really doesn't care what the name of the file is? Monticello stores all of the branching and ancestral information in it's meta data and the name of the file has no semantic meaning whatsoever.
>>>>>>
>>>>>> Finally, from a practical perspective have you actually tried to use your "proposed"  naming convention in a real project?
>>>>>>
>>>>>> I have just spent a few minutes experimenting with the Pharo tools using your "proposed" branch naming convention and it doesn't take long to recognize that the tools do not support this model very well - at all.
>>>>>>
>>>>>> I suggest that you actually spend some time trying to use this convention in a real project before suggesting that Squeak and GemStone adopt the convention. I will wait until I know how big a job I am faced with in converting the GemStone tool set to support the new model ... that work has not yet been done in Pharo, yet.
>>>>>>
>>>>>> As I mention in my original response, in the projects that I have been working on for several years now, where I do a lot of branching, I have found that the following pattern works _very_ well with all of the existing toolset on all platforms:
>>>>>>
>>>>>> packageName.branch-initials.count.mcz
>>>>>>
>>>>>> Dale
>>>>>>
>>>>>> On Feb 5, 2011, at 5:45 AM, Julian Fitzell wrote:
>>>>>>
>>>>>>> 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 <[hidden email]> 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<[hidden email]>  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<[hidden email]>
>>>>>>>>>>> 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
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> seaside-dev mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> seaside-dev mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> seaside-dev mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>