Hi Dave,

But isn't the problem rather that nobody who is seeking to contribute has
write access to the repository? Then you also could not save a Monticello
branch to it. The thing about GitHub/Bitbucket/... forks is that they are
separate repositories, and therefore have different access rights.

Kind regards,
Jakob


Am Fr., 7. Okt. 2022 um 00:13 Uhr schrieb David T. Lewis <
lewis at mail.msen.com>:

> 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
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
>
>
>
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221007/82d663a6/attachment.html>