<div dir="ltr"><font color="#330033"><font size="2"><font face="tahoma,sans-serif">Thanks all of you guys. Nick - I've read these articles before, they are really helpful.<br><br>So... isn't Monticello supported/maintained by someone? is it implemented by the needs and wants of different Smalltalk dialects?<br>
Monticello versioning, and the image directory access (asked on another thread) always remind me of the inefficiency of having different language dialects... and it comes second-hand to me since I've dealt with LISP & Scheme dialects.<br>
<br>I like the idea of Grease, but that too comes with a set of limitations.<br>I prefer having an *extension* of some sort that can gap the dialects' differences, but that will require a large cooperation from everyone's dialects.. </font></font></font><font color="#330033"><font size="2"><font face="tahoma,sans-serif">Does this "dialect wars" have an ending? I don't see the point.</font></font></font><br>
<font color="#330033"><font size="2"><font face="tahoma,sans-serif"><br><br>Cheers,<br>Avi.<br></font></font></font><br><div style="margin: 0pt;" name="sig_83fa755cf9"></div><div class="gmail_quote">On Fri, Feb 4, 2011 at 6:15 PM, Julian Fitzell <span dir="ltr"><<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">The Squeak one should (have)... it's been built into MC since the dawn<br>
of time. As I said, though, it was never really well-known and got<br>
broken at some point by someone changing the code. It may be that I<br>
only pushed to have the fix included in Pharo and Squeak never<br>
followed suit. They should though - it's definitely not<br>
Pharo-specific.<br>
<font color="#888888"><br>
Julian<br>
</font><div><div></div><div class="h5"><br>
On Fri, Feb 4, 2011 at 2:58 PM, Dale Henrichs <<a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a>> wrote:<br>
> 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.<br>
><br>
> Sigh....<br>
><br>
> Dale<br>
><br>
> On Feb 4, 2011, at 6:34 AM, Julian Fitzell wrote:<br>
><br>
>> Good point, Dale.<br>
>><br>
>> The best option is probably to use Monticello's branch naming convention:<br>
>><br>
>> <package>-<initials>.<branch>.<count>.mcz<br>
>><br>
>> The MC UI will maintain all the dotted segments, incrementing the last<br>
>> segment (count) on each commit. It got broken for a while, but recent<br>
>> version of MC have it fixed again.<br>
>><br>
>> Using this pattern means the tools will maintain the branch for you on<br>
>> each subsequent commit and the versions will still show up in the<br>
>> version list for the package.<br>
>><br>
>> Julian<br>
>><br>
>> On Fri, Feb 4, 2011 at 1:33 PM, Dale Henrichs <<a href="mailto:dhenrich@vmware.com">dhenrich@vmware.com</a>> wrote:<br>
>>> Avi,<br>
>>><br>
>>> 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.<br>
>>><br>
>>> I have had success over the years using the following pattern:<br>
>>><br>
>>> Seaside-Core.IssueXXX-<initials>.<count>.mcz<br>
>>><br>
>>> This pattern will not be inadvertently interpreted as a Seaside-Core package by Gofer/Monticello and is very readable.<br>
>>><br>
>>> Dale<br>
>>><br>
>>> On Feb 3, 2011, at 10:41 AM, Avi Shefi wrote:<br>
>>><br>
>>><br>
>>> Hi,<br>
>>> 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?<br>
>>> The best option I can think of is:<br>
>>> 1) do your work on the issue<br>
>>> 2) save it to a mcz file named: Seaside-Core-<initials>-issueXXX.mcz<br>
>>> 3) reload the original ancestor from which you started<br>
>>> 4) keep working on other issues without having the code of the previous fix inside the image<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Is this the right way?<br>
>>><br>
>>><br>
>>> Thanks,<br>
>>> Avi.<br>
>>><br>
>>> <ATT00001..txt><br>
>>><br>
>>> _______________________________________________<br>
>>> seaside-dev mailing list<br>
>>> <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
>>> <a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
>>><br>
>> _______________________________________________<br>
>> seaside-dev mailing list<br>
>> <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
>> <a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
><br>
> _______________________________________________<br>
> seaside-dev mailing list<br>
> <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
> <a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
><br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</div></div></blockquote></div><br></div>