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