> On Oct 6, 2022, at 3:13 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> Monticello does not directly support branching or forking as one might
> expect to find it in git, or in conventional version control systems
> (SVN, CVS). However, we do have a simple approach to handle the kind of
> situation discussed in this thread.
> 
> To see how it works, open a Monticello browser on package Compiler in the
> trunk repository. Highlight the latest version (Compiler-eem.479 as of
> this writing) and open a History browser on it.
> 
> Now, in the same trunk repository browser, scroll down to package called
> Compiler.spur. Highlight the latest version (Compiler.spur-eem.304) and
> open a History browser on it.
> 
> In the history for Compiler.spur, you can look at the history, and especially
> look at the Ancestors for each of the versions. You can see the earliest
> common ancestor at Compiler-cmm.297 (UUID: 1d7e980a-3504-44fa-9a9c-803bf3a6bda2),
> and you can see that the more recent versions in the Compiler.spur branch
> descend from this common ancestor, and also show occasional merges from the
> master branch. For example, Compiler.spur-eem.298 shows two ancestors
> (Ancestors: Compiler-eem.298, Compiler.spur-cmm.297) so this is analogous
> to a git merge in which the Compiler (master) branch has been merged into
> the Compiler.spur (feature branch) branch.
> 
> Why was this done? Eliot needed to set up a "spur branch" for developing
> his new Spur image format, and he needed to be able to work in this branch
> at the same time that development was proceding in trunk. The 'Package.branch'
> naming convention in our Monticello tools enabled this for Compiler and other
> core packages. Eliot was able to work in the spur branch, merging as needed
> with trunk, and when the entire project was ready, he did a final merge
> (and some other magic) and we all switched over to the new Spur image format.
> 
> The 'Package.branch' naming convention can be used for a variety of use
> cases that might otherwise be supported by git branching or Subversion
> forking. For example, suppose you have package RayTracing in a repository
> on squeaksource.com, and the most recent version is RayTracing-avi.6
> (which is almost 20 years old now). If we want to preserve Avi's master
> branch while accepting inbox updates, then we might agree to use package
> RayTracing.inbox.  Then, if I were to commit a new version, I would save
> my new version as RayTracing.inbox-dtl.7.mcz. This would establish a
> RayTracing.inbox branch, and the repository owner might choose to merge
> my contribution into the main RayTracing branch, or they might simply
> choose to leave it in the new branch.
> 
> Another similar approach might be to establish a branch called RayTracing.trunk
> to contain ongoing updates for newer Squeak versions. That would preserve
> Avi's original master branch, while allowing newer updates to be maintained
> in the RayTracing.trunk branch. There really would be little or no need for
> a separate inbox in this case, since there is probably a very small number
> of people working on it. Those people probably know what they are doing,
> and any issues would be easily sorted out on the squeak-dev list.
> 
> If, for this case, we decided to establish a new RayTracing.trunk branch
> for ongoing development, then the simple first step is for someone with
> commit access to the repository to open RayTracing-avi.6.mcz and re-save it
> as RayTracing.trunk-xyz.7.mcz (where xyz are your author initials). Then
> send an email to squeak-dev to say that RayTracing.trunk is open for
> contributions.

+1.  I would like to see the above edited and included in the Squeak help tool under the Monticello section as a guide to branching in Monticello.

> 
> HTH,
> Dave
> 
> 
>> On Thu, Oct 06, 2022 at 09:41:17AM +0200, Jakob Reschke wrote:
>> Just to relate with the outside world: GitHub, Bitbucket & Co have "forks"
>> as a solution. Since Monticello is distributed, Squeaksource could offer
>> the same feature.
>> 
>> To serve the purpose of reviving abandoned projects, such forks would have
>> to be made easily visible on the original project's page. Because without
>> project admin access, the original project description will obviously not
>> change to point to the newer repository.
>> 
>> Depending on the implementation it could be nearly the same as the inbox
>> proposal of Chris. Just that forks are not publicly writeable.
>> 
>> 
>> 
>> karl ramberg <karlramberg at gmail.com> schrieb am Mi., 5. Okt. 2022, 22:45:
>> 
>>> 
>>> 
>>>> On Wed, Oct 5, 2022 at 10:38 PM Chris Muller <asqueaker at gmail.com> wrote:
>>> 
>>>> The easiest tweak I can think of would be to add a "Inbox" tab to the
>>>> Project page.  Anyone can then be allowed to submit to the project.
>>>> Internally, all versions are stored in the same project directory, but the
>>>> legacy Versions tab would be changed to filter only the versions which are
>>>> authored by those with write access, while the Inbox tab would show those
>>>> without write access.
>>>> 
>>> 
>>> +1
>>> 
>>> Best,
>>> Karl
>>> 
>>>> 
>>>> [image: ss-inbox-idea.png]
>>>> 
>>>> Without the above, since only admin-level can delete submitted versions,
>>>> and configuration is a separate issue from source code repository, I've
>>>> started opening up my repositories for public write access.  Why did I ever
>>>> think I wanted to discourage contributions?  It theoretically opens them up
>>>> for spam attacks, but we haven't seen that with our Inbox.
>>>> 
>>>> - Chris
>>>> 
>>>> On Wed, Oct 5, 2022 at 1:01 AM karl ramberg <karlramberg at gmail.com>
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> I made a small fix for the RayTracing project.
>>>>> http://www.squeaksource.com/RayTracing.html
>>>>> Vector needed to subclass Float32Array instead of FloatArray.
>>>>> 
>>>>> But the RayTracing project is read only.
>>>>> 
>>>>> Do we have a best practice for stuff like this?
>>>>> I uploaded the fix to my own squeaksource account
>>>>> 
>>>>> Best,
>>>>> Karl
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
> 
> 
> 
>> 
> 
>