Here's what I see on the Linux box:

Try:

fossil sync -verily

That will force it to ignore certain shortcuts which can, in exceedingly rare cases, cause symptoms like what you are reporting. It only needs the -verily option one time, not for all future uses.

Thanks for the suggestion. Sadly it has no effect.

In case it's relevant, I have autosync switched on, and I generally rely on an ordinary commit.

Sadly it has no effect.

i unfortunately don't have any other suspicion or suggestion other than re-cloning.

If you have local changes you want to keep, do the following from your checkout to retain them (with the caveat that this will lose any "undo" and "stash" state):

fossil close --force
fossil open --keep /the/new/clone.fossil

Still no luck:

$ fossil open https://uuuuuuuu:pppppppp@chiselapp.com/user/uuuuuuuu/repository/rrrrrrrr --workdir work/myStuff

fossil clone 'https://uuuuuuuu:pppppppp@chiselapp.com/user/uuuuuuuu/repository/rrrrrrrr' /home/user/rrrrrrrr.fossil

remember password (Y/n)?

Round-trips: 2 Artifacts sent: 0 received: 180

Error: login failed

Round-trips: 2 Artifacts sent: 0 received: 180

Clone done, sent: 661 received: 7871447 ip: 2607:f1c0:84b:4b02:68e8:7a3f:2812:3fc0

server returned an error - clone aborted

clone of https://uuuuuuuu:pppppppp@chiselapp.com/user/uuuuuuuu/repository/rrrrrrrr failed

I am confident that the username, password and repository name are all correct.

I am confident that the username, password and repository name are all correct.

That's not something we can help you with - you'll need to contact Roy Keene (the site's operator). Make sure, though, that you are using the login for that repo, not your Chiselapp credentials. Those are separate things.

Are you sure I need the "login for that repo, not my Chiselapp credentials"?

From the chiselapp dashboard, the "how to clone" instructions for authenticated cloning are to do fossil clone https://uuuuuuuu@chiselapp.com/user/uuuuuuuu/repository/rrrrrrrr rrrrrrrr.fossil

Where uuuuuuuu is my chiselapp username and rrrrrrrr is the repo name. (Actually I used my (chiselapp) username for the repository, so I'm guessing where uuuuuuuu and rrrrrrrr occur in the URL.)

Since it seemed to need the chiselapp username, I specified the chiselapp password as well.

Sorry to quibble, as I'm the one asking for help.

I can get the "project code" from the local repository (via fossil info) - will that be the same as on the chiselapp version, and if so, does it need to be specified somewhere in the URL?

From the chiselapp dashboard, the "how to clone" instructions...

Fossil has its own credentials. It's possible that Chiselapp is set up to apply its credentials to your repos, but i have no idea. It's a 3rd-party service, not part of this project.

I can get the "project code" from the local repository (via fossil info) - will that be the same as on the chiselapp version, and if so, does it need to be specified somewhere in the URL?

The project code is an internal detail - you should never need to even know that it exists. Fossil uses it to ensure that different projects' repositories don't sync with each other.

Thanks Stephan.

I've raised a ticket against Roy Keene's flint project on chiselapp.

I have since tried from a third machine, and I find that from that machine, I can synchronise successfully with my chiselapp repository.

To summarise, I have three machines:

A - Linux Mint 20.2, fossil 2.15 [2c6012c4aa]
B - Windows 10, cygwin, fossil 2.11 [63837f423f]
C - Windows 10, cygwin, fossil 2.11 [63837f423f]

I can sync from machine C, but not from A or B.

Notes:

1. The SSL certificate at chiselapp is currently invalid. On all three machines, I have accepted the certificate anyway; on A and B at some point I've said to remember the exception but I haven't said that on C.
2. Some history:
   • I've had A for more than 5 years and it's the machine from which I've made the majority of commits recently. I think the last successful sync was from around the time that the SSL certificate expired.
   • B is a new machine, about 6 weeks. I probably set up the local repo to look as much like the one on A as I could.
   • I've had C for a couple of years. I had some trouble setting it up (it was the subject of my only previous posting on this forum) but it worked ok once I sorted that out. I haven't used fossil on it very much since then.

I completely appreciate that the issue may well be with chiselapp rather than fossil, but since the same version of fossil behaves differently on the same operating system (B and C), I still suspect that I may have got some configuration or settings wrong and would welcome any help tracking down what the misconfiguration might be.

Many thanks.

The SSL certificate at chiselapp is currently invalid.

How did you check that? From my test it's perfectly valid for over a month yet. Are you having some issue with time synchronization on your machines?

OK there is a problem - not with chiselapp cert, but with Let's Encrypt signing cert.

So, Roy: maybe try to renew the cert?

My reply #15 answers these questions.

Windows 10, cygwin, fossil 2.11

That's unfortunate: the Fossil package appears to be abandoned on Cygwin. Worse, it appears that the latest ca-certificates package is about 16 months old at this point.

Have you tried the standard workaround, just as a test?

If that works, then I'd suggest one of two paths rather than continue using that workaround:

1. If you depend on Cygwin packages, one or both of these are probably up for adoption.

2. With WSL sucking all the oxygen out of the room, maybe it's best to abandon Cygwin.

The SSL certificate at chiselapp is currently invalid.

It verifies here.

I will note that they aren't automatically redirecting HTTP to HTTPS, though. Not only is that bad practice, it may explain your symptom: perhaps this "third machine" of yours is syncing over HTTP.

Andy,

Half the trouble is that fossil doesn't output anything untoward. While I was building machine B, I took pains to ensure that everything I had done on its predecessor was committed to the local repo, thinking that this would ensure it was all there on chiselapp for me to pull down onto the new machine. It came as something of a shock when it wasn't. I then spotted that the changes I'd been committing from machine A weren't there either.

Commits from B started syncing to chiselapp OK today (or possibly yesterday) when I happened to reconfigure the remote URL; it's quite likely that it was wrong previously. Commits from A still don't get sync'ed correctly.

Here's the result of executing fossil push on machine A (Linux Mint 20.2, fossil 2.16):

Push to https://ruuuuuuu@chiselapp.com/user/cuuuuuuu/repository/crrrrrrr
Unable to verify SSL cert from chiselapp.com
  subject: CN = chiselapp.com
  issuer:  C = US, O = Let's Encrypt, CN = R3
  sha256:  d40a8fdee44116a15bed3e9cdfa2e8cd3302e255892be81139da0c866d6ea3b4
accept this cert and continue (y/N)? y
remember this exception (y/N)? 
Round-trips: 1   Artifacts sent: 0  received: 0

Looking carefully, the numbers in the last line are fairly clearly "off". I noted just now, for the first time, that there is no newline after the counts, so the Round-trips are generally overwritten by the bash prompt for a new command. Needless to say, no changes have made their way to the chiselapp repository.

fossil remote-url returns the same on both two machines, except that I use a different repository username on each machine.

Apologies, Stephan.

While writing reply 20 below I reconfigured the remote-url. I confirm that this should be

https://ruuuuuu:rppppppp@chiselapp.com/user/cuuuuuuu/repository/crrrrrrr

where

cuuuuuuu and cppppppp are the chiselapp username and password; and

ruuuuuuu and rppppppp are the repository username and password.

Apologies, Stephan.

No need. Unfortunately, i don't have any further ideas :/. Syncing has always "just worked" for me, SSL or otherwise. FWIW, this machine is also Mint 20.2 (but it was 20.1 when this thread started).

The current state is that I can now sync with chisleapp from both machines running Windows using ctgwin and fossil 2.11, but I cannot sync from the Linux machine running fossil 2.15. I see 2.16 is now available; I'll try it presently.

AFAIR nothing has changed in the sync code in that time, but trying the latest version never hurts (well, almost never). For many of us the tip of the trunk is always "the latest release," and we generally recommend running the trunk version to users who are able to. There was a fix for SSL cert hostname verification in either 2.15 or 2.16, but that doesn't seem to be an issue, as you're able to sync from other machines.

Just out of curiosity, what happens if...

• From one of your Windows machines, sync with Chiselapp.
• On that machine, run fossil server --port 8080.
• From the Linux machine, run:

fossil pull --once -R the-repo.fossil http://your-windows-ip:8080

(If you're in a checkout, you can leave off the -R filename part.)

Does that pull the latest stuff to the Linux machine via the Windows machine? If so, we know that the problem is communication between your Mint and Chiselapp. If not, we know... something else.

The Error: not authorized to write is interesting (if uninformative),

i'm not certain, and haven't checked the code, but passing a url to --once probably doesn't use the saved credentials for the default url. You likely just need to add your login name to the url: http://name@matt...

$ (cd work/myStuff/; fossil push --once http://alan@matt:8800) password for alan: Round-trips: 1 Artifacts sent: 0 received: 0 Error: login failed Round-trips: 1 Artifacts sent: 0 received: 0 Push done, sent: 2080 received: 301 ip: 192.168.1.227

I'm assuming you meant me to specify the Windows login information :-)

I guess the number in the last row following "sent: " is the number of bytes sent over the wire. The number in the previous attempt looked very plausible.

I'm assuming you meant me to specify the Windows login information :-)

Nope - Windows plays no role in the authentication here. Fossil URLs always (even on Chisel) take a Fossil-specific login.

I guess the number in the last row following "sent: " is the number of bytes sent over the wire. The number in the previous attempt looked very plausible.

Correct: "sent" is over-the-wire bytes (including compression, IIRC, but there was a recent discussion about a discrepancy in that regard). The Artifact count is the number of blobs sent/received, so 0 is completely expected when nothing is synced. Your login failed, though, so sending those cannot have worked unless the remote accepts pushing from guest accounts.

OK, OK. Give me credit for always getting confused about credentials :-)

From a quick look, if seems I hadn't done much user setup on matt, having done some, the command now goes

$ (cd work/myStuff/; fossil push --once http://ruuuuuu@matt:8800) password for alan: Round-trips: 8 Artifacts sent: 48 received: 0 Push done, sent: 1307831776 received: 6491 ip: 192.168.1.227

From the Mint box

As before, no updates on chiselapp, and none on matt.

(Two side-questions: i) Is it possible to pull the user configuration down from chiselapp? ii) How do you do the quoting and highlighting in this forum? I've tried Markdown and Fossil wiki style and can't work it out.)

Round-trips: 8 Artifacts sent: 48 received: 0 Push done, sent: 1307831776 received: 6491 ip: 192.168.1.227

That sent 1.3GB of data in 48 blobs to the matt Windows computer, so something must have happened to matt.

As before, no updates on chiselapp, and none on matt.

That push won't update Chiselapp. It simply pushed the data to matt. If, from matt, you now to "fossil sync", it "should" send that data Chiselapp.

If you're not seeing that data on matt then i opine that "you ain't looking right." The push output clearly shows that it was transferred. Perhaps you're looking at a different copy of the repo or you have hidden the branch you're looking for, so don't see it in the timeline.

Size might be an issue: i have no idea whether Chiselapp imposes any size limits. It would not at all surprise me if that machine rejects transfers that big. (If i were hosting Chiselapp on a volunteer basis on my own hardware, i would do everything in my power to stop people from hosting repos that large.)

We know, from the above sync output, that your Mint machine can send data to matt:8800. Therefore, if your Mint machine cannot send data to Chiselapp then there's another factor we're not aware of. Firewall or a proxy server or Chiselapp transfer limits or any number of other factors outside of fossil's visibility.

(Two side-questions: i) Is it possible to pull the user configuration down from chiselapp?

You can pull the list of users:

fossil config pull user

But doing so is rarely of real use. The passwords pulled that way won't work. All passwords are hashed in such a way that the hash is only valid for that particular clone of a repository.

How do you do the quoting and highlighting in this forum? I've tried Markdown and Fossil wiki style and can't work it out.)

Tap the "source" link at the top of any post which contains such a thing and you'll see how it's done. Quoting has to be done by hand - it can't be done automatically because the forum supports 3 different, mutually exclusive, text formats.

If you're not seeing that data on matt then i opine that "you ain't looking right."

I can see how you might form that opinion. I'm basing this on pointing a browser at http://matt:8800/timeline and not seeing the latest changes, which I do seem to have pushed from the Mint box. This is how I'm looking at chiselapp and what leads me to think that the changes aren't getting there.

I've just tried doing a straightforward fossil push on the Mint box, so it goes straight to chiselapp; if completes much more quickly, but the last line is overwritten by the bash prompt for the next command. The last time I noticed it, it was still showing `Round-trips: 1 Artifacts sent: 0 received: 0.

(Thanks for the suggestion to use the "source" link; I hope the fruits of doing so are apparent a few lines above.)

I can see how you might form that opinion. I'm basing this on pointing a browser at http://matt:8800/timeline and not seeing the latest changes,

The push output disagrees, so two things to try:

• Force a page reload of /timeline. Normally that is shift-reload or ctrl-reload. You may be seeing a cached copy.
• View the timeline from the CLI, fossil timeline -R the-repo.fossil, noting that if the data are older then they won't appear in the CLI's output because it only shows the most recent activity by default. See "fossil help timeline" for how to change that.

Oops. I'm embarrassed to say that stuff is getting to matt ok. I might not have been seeing it because I needed to shift-R or ctl-R or whatever (I'm using firefox), or it might be because the additional commits happened before a couple of genuine commits from matt, so they weren't at the top of the screen.

The push from matt is now failing with an error

$ fossil push
Push to https://helga@chiselapp.com/user/nurdglaw/repository/nurdglaw
Unable to verify SSL cert from chiselapp.com
  subject: CN = chiselapp.com
  issuer:  C = US, O = Let's Encrypt, CN = R3
  sha256:  d40a8fdee44116a15bed3e9cdfa2e8cd3302e255892be81139da0c866d6ea3b4
accept this cert and continue (y/N)? y
remember this exception (y/N)?
Round-trips: 1   Artifacts sent: 0  received: 0
server says: 500 Internal Server Error
Push done, sent: 658653739  received: 1696  ip: 2607:f1c0:84b:4b02:68e8:7a3f:2812:3fc0

I suppose it's not completely unreasonable that the chiselapp server can't cope with 600Mb of data at once, though it would be nice if it could. Is there a way to do a partial push?

I think we've just worked out that there's a problem communicating between my Mint box and chiselapp. When we manage to sort this out, I anticipate that I'm going to run into a similar problem to the one I saw on matt.

Many thanks. It's getting late in the UK and I need to turn in, can we continue this on Monday?

server says: 500 Internal Server Error

Chiselapp is crashing there. Whether it's due to a transfer limit or a genuine fossil bug we can't say. We'll need Roy (Chiselapp's operator) to take a peek. We're not aware of any crashes during the sync process, so my completely uninformed suspicion is that Roy has a proxy between you and fossil which limits transfer sizes, memory use, and/or repo sizes.

Is there a way to do a partial push?

Nope. That would require significant changes to fossil, some of which have been discussed before in the context of "shallow clones," but it requires changes which are not easily made. If the limitation you're hitting is a RAM limit then a partial push wouldn't help because you have massive blobs which have to reside in memory during their transfer.

I've just tried to push from matt again, with the same result (modulo a small change in the exact number of bytes transferred).

I've also managed to find my way onto the Tclers chat group, where I see Roy is lurking, so I may be able to get hold of him to discuss the 500 Internal Server Error.

If I manage to get the server error resolved, I will (probably) still have a communication problem between my Mint box and chiselapp. Where would be the best place to get help resolving that? Here or via Roy?

I've got everything working again. Many thanks to everyone (particularly Stephan) for their patience and help.

I managed to get hold of Roy Keene and the problem was caused by a couple of database dumps which, even when gzipped were in excess of 600MiB. Roy has changed flint (the chiselapp software) to allow designated users to exceed the previous 512 MiB memory limit.

I had copied these dumps between machines A and B, but not to C which explains why I was always able to sync from there.

I assume I will continue to need the large memory space forever, even if the database dumps aren't affected by a commit.

As a final nitpick, I looked at the output of fossil commit many times without spotting the embedded 500 Internal Server error message. Could that somehow be made more prominent? Maybe a dirty great "ERROR" at the left-hand margin or bracketed with >>> and <<< ?

As a final nitpick, I looked at the output of fossil commit many times without spotting the embedded 500 Internal Server error message. Could that somehow be made more prominent? Maybe a dirty great "ERROR" at the left-hand margin or bracketed with >>> and <<< ?

I don't think that's warranted; it was immediately identified by Stephan from
your screen dumps and he even identified the likely cause as a result.

Glad to hear Roy has provided a solution for you.

I've got everything working again.

Great!

I assume I will continue to need the large memory space forever, even if the database dumps aren't affected by a commit.

For certain operations, those large files will impact fossil's memory usage greatly. The cases which comes to mind:

1. Clone and sync of those files, as you've discovered.

2. Checking in a change to one of them requires having both the old and new versions in memory at once so that a delta can be calculated and/or applied. (Fossil generally keeps the latest version of any given file in its full/undeltad form in the db and stores older versions as deltas.)

3. Generating a tar or zip requires memory directly proportional to the total contents of the version being tarred/zipped.

4. Rebuild (sometimes needed after a fossil upgrade) might need to load the whole blob and/or (re)create deltas, but i'm not 100% certain of that.

Other than that... i don't think your repo will need that much memory on a regular basis. If it does fail, though, then we now know why!