Hi all,
anybody objects if I merged BlockClosure>>#on:satisfying:do: and #on:satisfying:ensure: as proposed via Kernel-ct.1303? Since originally writing this proposal, I really have missed something like this in the trunk. :-)
Best,
Christoph
---
Sent from Squeak Inbox Talk
On 2020-11-07T12:50:10-05:00, lewis@mail.msen.com wrote:
> On Sat, Nov 07, 2020 at 03:58:58PM +0100, Jakob Reschke wrote:
> >
> > Am Sa., 7. Nov. 2020 um 13:51 Uhr schrieb Christoph Thiede
> > <christoph.thiede at student.hpi.uni-potsdam.de>:
> > >
> > > Hm ... I just tried to upload Kernel.ct.1362-ct.2 (branch name: "ct.1362"),
> > > but it was uploaded as Kernel-ct.1362 ... The next time I will try it
> > > without a dot in the branch name. :-)
> >
> > So yes Monticello can produce branches, but it seems all but obvious
> > how to use them (right).
> >
>
> For a memory aid, look at the packages 'Compiler' and 'Compiler.spur' in
> trunk. The entries in Compiler.spur are of the form Compiler.spur-eem.287,
> so the naming convention when saving a branch version is to add '.spur'
> the the package name 'Compiler' to get 'Compiler.spur'. The '-eem' and
> '.287' are author and file version number. The actual branching is seen
> only in the version history of any of these version entries, and it may
> not match the history implied by the names.
>
> For the example that Christoph provides above, suppose that Christoph was
> working on the Kernel package, and he wants to save some inbox versions
> branched from Kernel-eem.1361. In this example, the changes are going
> to be related to Context>>runSimulated, so he might want to identify
> these as a feature branch called 'runSimulated'. in that case, he
> might enter the name 'Kernel.runSimulated-ct.1362' rather than
> 'Kernel-ct.1362' when saving 1362 to the inbox. Then, when saving
> the next version 1363, it would be saved as 'Kernel.runSimulated-ct.1363'.
>
> This system is far from perfect, but it does work. Do not expect it to
> be as elegant or efficient as git, it is not.
>
> As Jakob says, the above is not obvious and that's why I mention it here.
>
> Dave