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

Nick Ager nick.ager at gmail.com
Fri Feb 4 16:01:36 UTC 2011


Hi Avi.

You may find these blog posts on Lukas's blog helpful:
http://www.lukas-renggli.ch/blog/monticello-merging
http://www.lukas-renggli.ch/blog/gofer

Nick

On 4 February 2011 14:58, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20110204/c2a37ee7/attachment.htm


More information about the seaside-dev mailing list