Goodbye GitHub ... ?


I don't know how to explain it, it's a whole package, right now I'm configuring ZFS and using a jail, it's interesting, otherwise what do I do: just throw Fossil into a VPS + Docker and that's it?

Another point is that my confidence in FreeBSD is increasing while my confidence in websites and the network is decreasing. Last night, I lost access to Proton Drive and Mail, but it was back this morning. Very often on Sunday afternoons, GitHub is very slow (maintenance, network load?). Even if the network is down (and this happens here in case of strong winds or thunderstorms), I can still work on the LAN, not to mention Fossil's ability to operate offline.
 
Sounds complicated. I personally prefer "to code" more than configure web servers.
Why not: 1) try to place the 'main' repos in: ~/repositories.fsl or 2) try the ssh(1) method I suggested (push/pull via ssh(1)) (ie, configure a user and install a VCS program [git, got, fsl, svn,...], set up ssh.conf)?
 
Why not: 1) try to place the 'main' repos in: ~/repositories.fsl or 2) try the ssh(1) method I suggested (push/pull via ssh(1)) (ie, configure a user and install a VCS program [git, got, fsl, svn,...], set up ssh.conf)?
I really do not understand. How will the remote repo see the local checkout?

Basically, Yes
For what docker?!

He needs the remote repo acting as a server, accepting connections, this is done by fossil either as cgi, or run by inetd,
or run as stand alone.

Why to inflate everything with docker, jail, containers, etc?!
To run a web server serving cgi is very easy and it is the most stable way to run fossil in my opinion.
If not, then to put a line in /etc/inetd.conf and enable inetd in rc.conf is really no work.

The web server, ngix or apache, and fossil as server, runs in a cheap Linux VPS exactly as it runs in FreeBSD.
Why should this disturbing to someone that wants to work with FreeBSD?
 
You guys are silly. Programmers who don't like to actually write programs but like to configure stuff instead.

My latest project has 16,000 lines of code, so don't tell me I don't like writing code. Whatever you do, you have to configure it, starting with the OS itself. The same goes for the code editor, compilers, VCS, static analyzers, coding agent, ... My project itself needs configuration: 180 lines of Makefile, including 50 lines of options for a simple AVR microcontroller. In the end, adding jail and caddy doesn't change much.
 
How will the remote repo see the local checkout?
It does not. You set up other repos to contact in Your end, and then you can push/pull with them. That might be a path in the file system, a URL, ... You need to be allowed to push on the other end, though, if that is enabled.
 
It does not. You set up other repos to contact in Your end, and then you can push/pull with them. That might be a path in the file system, a URL, ... You need to be allowed to push on the other end, though, if that is enabled.
You mean to run the VCS client remote and the VCS server local, using DynDNS?

Because I don't want Linux and I want to stay local. If it works with FreeBSD, why use Linux?
If you want to stay local, then you can use fossil or other VCS, including CVS, with FreeBSD locally. No problem.

If you want a cheap remote VPS for keeping a remote copy, for syncing your repo, then you must use the OS the provider supports, probably Linux. Or perhaps use github, chiselapp & Co.

I got used to sync with self hosting remote repo, an easy way to backup work. And when I change the computer, an easy way to transfer data and continue working as usual. It makes life easier.
 
You mean to run the VCS client remote and the VCS server local, using DynDNS?
No, there is no dedicated server binary, nor a client binary. I used the rc script in /usr/local/rc.d/fossil, set up the required data in the rc.conf on my RPi4 and was a happy camper. I also have used remote paths lile /nfs/... or /media/windows/Documents/Fossils/ ...
You then pull/push with that repo. A "server" is only needed to run when it's a network connection. And that's the exact same binary that you use on your end. "fossil help remote" is your friend here.
then you must use the OS the provider supports, probably Linux
Yes. A POSIX network stack, but no Linux is required. It works on Haiku, btw. So you can turn your old 32 bit laptop into a nice VCS hub in your home, or small company.
 
No, there is no dedicated server binary, nor a client binary. I used the rc script in /usr/local/rc.d/fossil, set up the required data in the rc.conf on my RPi4 and was a happy camper. I also have used remote paths lile /nfs/... or /media/windows/Documents/Fossils/ ...
I did not know that there is a /usr/local/etc/rc.d/fossil, but it starts fossil as server.

Remember, fossil binary is a Swiss knife, it contains a server and a client.

fossil remote is for syncing (push / pull) local repo with a remote named there. You do not need it if you work only locally.

You then pull/push with that repo. A "server" is only needed to run when it's a network connection. And that's the exact same binary that you use on your end. "fossil help remote" is your friend here.
For that, for VCS, you do not need to start the server as above. You need it only for seeing the repo with a browser. You can instead do fossil server in the check out dir and get the same, fossil ui also opens the browser.

You can have fossil repos anywhere, collect repos in any directory, and check out a repo anywhere else, also check out the same repo in different locations. This is a little different from standard git.
 
In the end, adding jail and caddy doesn't change much.
caddy could be a good idea if it is really easy to configure https with ACME.

For fossil, and sure other VCS, you will need TLS for security, and perhaps it is not very simple to configure ACME.
 
If you want a cheap remote VPS for keeping a remote copy, for syncing your repo, then you must use the OS the provider supports, probably Linux.
There are a number of VPS providers that have FreeBSD available. I pay $2/month for mine. Some are as high as $5 for their cheapest. So, no, it doesn't have to be "probably Linux".
 
Nothing needs to "see" anything (I don't know what that is). When you push/pull local talks to remote (either via https or ssh). This is true for the many VCS programs I've used.

Sorry, is 16,000 lines of code a benchmark of some kind? 180 lines of makefile; my last makefile (the one I just wrote) was 10 (maybe) so I don't understand that benchmark either. Should I add more lines? ...oh wait! I just checked one of my other makefiles and its 270 lines. What do I win?

I don't understand the fossil repos in different directions or the same repo in several locations or even moving repos. This is true for all the decentralized VCS that I've used.

I think you guys have been talking to the slop bots too much (or you could be fairly new to version control) but if you got a slop bot by your side, I'm sure they won't steer you wrong this time (or anymore). You guys keep going.
 
The good thing about fossil is that most (all?) of the "coding tools" don't know about it and can't talk to it directly. So no messing with commit messages.
 
The good thing about fossil is that most (all?) of the "coding tools" don't know about it and can't talk to it directly. So no messing with commit messages.
Oh, I think I understand this one. ...I've always been a editor + compiler guy so even when I was using VS I still had a term open.

I'm not sure any of the modern VCS packages have anything terrible about them but I tend to keep my operations as simple as possible (I try to only care about important things to me). For example: I keep 'main' buildable so if I have an idea, I'll clone the repo to another directory and try my idea (if it works, I push otherwise I delete the copy). This keeps me from having to create/do branch management. I've hit a few of the nastier edge cases in all of them in the past so simple is better for me. I guess if I had to pick a fault in FSL, I would say it is the UI thing (I prefer text files readable/searchable).
 
I don't understand the fossil repos in different directions or the same repo in several locations or even moving repos.
I suppose you mean this sentence:

You can have fossil repos anywhere, collect repos in any directory, and check out a repo anywhere else, also check out the same repo in different locations. This is a little different from standard git.

I just copied it and pasted it in google AI and asked, what this sentence mean. Try it!

This is true for all the decentralized VCS that I've used.
In CVS, but not git, got reintroduces it.
 
I seriously don't understand what you mean or where you've had problems previously.
I have zero problems pushing to my local git server and github and wherever I want with one "push/pull all" command.
I have zero problems moving my bare repositories anywhere either.
I really have zero interest in typing to google ai. I don't have any problems with my setup whatsoever so why would i?

CVS? I'd have to take your word on CVS.

I really don't know if you're trying to prove you're an expert or not, but you can certainly own that title if you want (I don't care: zero fight from me). I've used fsl, git, rcs, hg, svn, and probably more (I don't care) and for what it's worth it looks like the fsl I have on my laptop is 2.23. The only time I ever setup a webserver was when gitlab and/or gitea set one up for me. If you or anyone wants/needs a web server, docker, or whatever, have fun. I personally would not spend more than 10/20 minutes setting up a VCS server.
 
Neither an expert nor wanting prove it. Your sentence is a projection: you are the one trying to do it.
I just wanted to point at:

Sure. Okay. Fine. Nice. Whatever. I just recommended setting up behind ssh(1) and I find it interesting how/what you guys are placing importance to (because I don't/wouldn't).

How is your point/workflow any different than git clone --branch for example? I guess I don't understand the objective (or why that has to be a thing for/against a VCS program).
 
Back
Top