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.

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
> >>>
> >>>
> >>>
> >>>
> >>
> >



>