Hi!

I got Fossil to work on MorphOS in the morphos branch. I successfully cloned https://objfw.nil.im/, made two commits and pushed them, so it even works with somewhat larger repositories that require multiple round trips. It is a bit slow, but that is due to the combination of 20 year old hardware and the UNIX emulation layer ixemul.

The changes are quite minimal, in my opinion, so it would be nice if this could be merged. The contentious change is probably the change to the embedded SQLite and jimsh. It is a quite minimal change to get SQLite running via ixemul on MorphOS, so I hope this can be merged into SQLite, given the Fossil developers and SQLite developers are mostly the same. What would be the best process for this? Should I sign up on the SQLite Fossil and post on the forum? I've signed the CLA for Fossil, so I guess that should also be good for SQLite? The jimsh patch is already upstreamed.

The only thing I could find that is not working yet is the integrated HTTP server. This is due to the fact that ixemul does not emulate fork, so a larger refactor would be required that makes it fork-less. That would probably also benefit Windows. But since that is something larger, that probably demands its own branch.

The next release of MorphOS, 3.20, will very likely also include Fossil in the SDK, making it the probably the first OS to ship with Fossil in the SDK.

I've signed the CLA for Fossil, so I guess that should also be good for SQLite?

Unfortunately not - SQLite. SQLite has its own contract, and any source code in SQLite (as opposed to infrastructure tools, like autosetup) is required to have been written by the one doing the checkin. When someone posts SQLite patches which are accepted, they're used as a proof-of-concept and rewritten/reformulated unless they're so trivial that they can't sensibly be expressed some other way (that is the case, IMO, for your particular patch).

If drh doesn't see this i'll point it out to him as a candidate for an upstream patch. "The problem," though, is that we have no way of testing it beyond setting up MorphOS, a burden neither of us will want to take on. Whether your patch really warrants that particular concern is debatable, of course, and IMO it's not a concern in this case, but the decision is ultimately drh's and that factor will certainly be part of the equation.

Please keep the MorphOS port off of trunk for now. Rationale:

1. Asking "can I merge to trunk" is really a nice way of asking "will you take over maintenance of this for me". No, I don't have the bandwidth for that right now.

2. There are a lot of "#ifdef IPV6" in parts of the code that are complicated enough already.

3. There are changes to upstream: SQLite and autosetup.

4. The MorphOS user community seems capable of taking care of themselves. It will not be a terrible hardship for them to have to pull the code from a branch other than trunk, or to contribute occasional bug fixes or updates to the morphos branch.

That said, if you want to continue supporting the morphos branch, by merging trunk updates into morphos periodically, that would be fine. You are welcomed to do that. Notice that I do something similar for some long-running branches on SQLite, rather than burden the trunk with unnecessary #ifdefs. See one example of this at: https://sqlite.org/src/timeline?ml=bedrock*+wal2*.

That's a sad outcome, but let me make some arguments to see if they can be convincing:

1. I don't understand how getting this merged is a request for you to take over maintenance - I'm quite happy to maintain it. And should I not, it's very easy to remove it again. I don't foresee any maintenance burden in any case, really. The patch doesn't touch the code paths for any other OSes, so the worst thing that could happen is that MorphOS support breaks. Which is no worse than the current situation which is no MorphOS support at all. If things break in the future, I'm also happy to fix them.

2. Yes, it's debatable if #ifdef IPV6 is the right one here. This applies for any OS that does not have the new name resolution APIs that were added to POSIX roughly the same time as IPv6. I'm quite surprised how the DJGPP port works without this?

3. Yes, which is why I asked about upstreaming those to SQLite. I'm puzzled about where I patch autosetup. Isn't auto.def specific to Fossil? It contains a lot of Fossil things. Did autosetup upstream an auto.def specifically for Fossil?

4. It's usually always better for everyone involved if everything is upstream. That usually improves maintenance for everybody, makes ports to other OSes easier and makes further development easier (see below). I'm happy to refactor things if you think instead of #ifdefs, they should just be properly abstracted, which is a fair point to make.

I would still be eager to get MorphOS support upstream, the reason being pretty simple: Branches of branches. Let's say I create a branch to add color support to diffs (which on MorphOS makes a lot of sense since it's less convenient to pipe things through something like colordiff and less). Now, given I do the development on MorphOS, I have to base these changes on the morphos branch rather than on trunk. How could color diff support ever be merged then, later on, given Fossil has no rebase?

With this in mind, I'd be very interested in finding another way to allow upstreaming MorphOS support that would be acceptable to you.

How could color diff support ever be merged then, later on, given Fossil has no rebase?

Cherry-picking.

Wouldn't that be pretty bad, cherry-picking an entire branch with double digit commits?

How could color diff support ever be merged then, later on, given Fossil has no rebase?

See Rebase Considered Harmful section 2.1:

A rebase is just a merge with historical references omitted

Fossil does support merge. It just chooses to remember all the parents, rather than forget some of them as Git does. There is no loss of capability.

So if somebody adds something to trunk that you want to incorporate into the morphos branch, all you do is merge:

fossil up morphos
fossil merge trunk
#  run tests...
fossil commit

I'm talking about the other way around. I need the changes that are in branch morphos to do any development at all, since Fossil needs to run in order to develop it further. So that means all my changes are created based on branch morphos. So if I create a branch colordiff, this one would be forked from morphos, not trunk. Now, if we want to merge the branch colordiff later, this would automatically bring in the changes from branch morphos, too. So how would we do this then if we want to merge colordiff to trunk, but not morphos? That would only work with a rebase of colordiff on trunk - which we can't do.

One approach:

• Branch colordiff off of trunk
• Periodically merge colordiff into morphos-colordiff which is branched off of morphos for testing.

Another approach:

• Branch colordiff off of morphos
• Later when you are ready merge colordiff back into morphos.
• Cherrypick the merge over to trunk.

There are probably other ways to do this, but those are the first two that come to mind.