 A while ago, I did a video on GET and why I thought GET needed to get good, as I put it, and wound up talking about Fossil, which is normally my go-to source control manager, or revision control system, or version control system, or whatever you use to refer to these things. I got a request to talk about Fossil, and this was something I actually had planned to do. I've been busy and had some other things I wanted to do, but I'm more or less prepared to do this now. I'm not going to get hardcore into details, mostly because Richard Hipp already has an absolutely great presentation on some issues with GET and why Fossil has a better approach, in his opinion. He's the author of Fossil, so obvious biases, but inevitably, when you are the author of a product, you designed it a certain way, because you had needs for it to be that certain way. We'll start off with installing it. If you're on Linux, or BSD, or anything like that, the installation procedure is fairly straightforward. Use your package manager. It's going to be called Fossil, end of story. On Windows, if you are running a recent enough version of Windows, you will be able to use Find Package and Fossil, or it'll say, from the Chocolatey source, there is a Fossil package available. If you are not on a recent enough version of Windows, and the Find Package and other package management commandlets are not present, you can install Chocolatey directly, although you can also just go to the Fossil webpage and download the binary there. The only thing you'll have to be aware of with Windows is, by default, the search path is a little not what command line junkies typically expect, but it's not particularly hard to have it set up. Now, in my case, I have it set up so that anything that Chocolatey and others wind up installing gets automatically put in there, so what I can do is install package and Fossil. Because there's only one provider, I don't need the specifier for provider, and then I can just go ahead and get this installed. And now, it should be good to go, granted with a very odd looking command name, but as you can tell, it gets a bit confused, but it still runs exactly the same. On say like Linux, that would look a lot cleaner. Fossil does something a little bit different from many other version control systems, especially distributed version control systems that sort of confuses some people. Fossil is almost like a hybrid of the centralized version control and decentralized version control, and it follows this in a lot of ways. One thing you'll need to keep in mind, much like with centralized version control, is that the repository is separate from your working directory. So I'm going to create the actual repository first. Now I'm going to move over to a different drive, which apparently, yes it does. Why are you, why, why, do I have it assigned to a different, it's different, no. Oh yeah, I have an issue to resolve involving this connection not being made initially. So it was trying to connect when, it was trying to move to the drive when the connection hasn't been made yet. It used to auto mount it, and then after an update that stopped, and I just haven't tracked down the error, because it's not that big of a deal, but I obviously need to get around to doing that. So I actually want to create the repository itself over here. And this is done through Fossil, I think just newer work. I've been using get so much recently, and much as I hate get, using it for all the stuff that I hope people will contribute to has caused me to forget some of the Fossil commands, but I think it's just in it. So I have the actual repository name, and what this is actually, or should be unsurprising if you recognize who Richard HIP is, is actually a SQLite database. That's it, just that single file is the repository. And it's obviously set up a special way, but it's just a SQLite database. Now you can name this anything, the extension doesn't matter. And in my case, I'm just going to create a repository for the spin objects. I haven't really done anything with them. So, but I have a test file in that for the VS code extension I was developing. So you can check that in there, and it should work fine. Should not take this long though. No, no, look, yeah, look like it went through. Okay, okay. So one of the first things you're going to want to do, of course, is configure it. And this is one of the actually really big selling points, except it's free, behind Fossil. I don't have to do anything. There's already a full website with branches and tags and even a ticketing system, a wiki system, and configuration is done through here. Assuming that it doesn't, or good. One of the things I'm going to do is, that's an interesting rendering error. I would not recommend doing this in the majority of cases, but since I am the only developer and I don't want to mess around with other things and just giving myself full permissions. In a team setting, like if anybody else winds up contributing to this, which is unlikely because the spin objects thing is not actually going to be public, then I would scale back my own permissions and, you know, assign them just the permissions they need and similar. But it's a very convenient way of managing this kind of stuff. And of course, contact info. I'm not going to bother with that. And a password, I will deal with this later. One of the other admin tasks I strongly recommend doing at the beginning, I believe it's here. Yes, the actual project name, which of course you do not want unnamed Fossil project. Yeah, we'll just leave it as that. It's not really that important. It's an internal project, so it's not like this would be something that search engines would really scan because it's internal. And that should go through. I'm not entirely sure why it doesn't go through the very first time when you had apply, but it, as you can see, did actually go through. One setting I strongly recommend doing if you are intermixing operating systems is the carriage return new line glob. Let's just do that. If you're only, if you're in a controlled environment where you can guarantee that the only checkouts and the only place you get commits from and all the editor settings and everything follows a specific convention, then you don't really need to worry about that. But if you're very intermixed, just that's going to help out a lot. Other than that, this is good for now. You know, obviously fill it out more as time goes on, but that's basically it. You know, anything you want to add to the wiki, all that stuff, just do whatever you feel like. And we can go ahead and stop that. And yes, but as you notice, this isn't really anything you can work with. So again, much like with a centralized version control, what you actually need to do is check out from this repository. Now, true to decentralized systems, you can actually have tons of these repositories exist on the same machine, on different machines, and they can all, you know, push to each other, pull from each other, all of the things that you would expect to see with decentralized, or decentralized version control are present. They're just, you can reasonably operate Fossil like a centralized version control as well, which actually has quite a bit of uses, especially when you have, say, like a team of developers on one machine or one server that hosts the repository. They can all have their working directories and then just commit to the same repository, then push out from the business onto, say, GitHub, well, it's not, it wouldn't be GitHub, but that same idea, they can push out to chisel app or wherever else. Or in the case of, say, multiple teams within an organization, they can, each team can have their own repository on their system and then, you know, push and pull throughout the entire organization, as opposed to with, say, Git, where the repository and the working directory are the same thing. You're left with, say, oh, I've seen somebody complain once that they had 32 different instances of the same repository on the machine just because they needed for the entire team, 32 different checkouts. It's a little crazy, especially trying to synchronize the changes between all of them. So what we can do for this, I'm just going to move back over to the desktop. And we can go into the existing directory and then it should just be fossil open and then we're open. This directory just became the working directory for this repository and I can show that through, I think it's fossil status. Yes, so we have an additional empty check-in. Now, one of the things I commented on really liking about fossil and just finding absolutely obnoxious about Git is the way changes to existing files are done. In fossil, when we want to add a file, it can be done through a simple add and then I can just go ahead and add the test object. Now, when I want to commit that, I can go ahead and commit and give it a message by default. If you just fossil commit, it'll bring up the system default text editor. I don't want to configure this on Windows, so I'm just passing it through the command line, which is fine because both the command prompt and PowerShell have, what's the term for them? The command line editors, anyways. So we're not talking about the really old days where you just type it in once and you can move through and edit the message. And of course, because that's what it is. Now, even though we're in the working directory and not on the repository, because the working directory knows what repository it came from, we can still do this. The only difference is because we're in the working directory, it opens from the timeline because that's usually the most interesting thing when you're working on things. So there was nothing for me to configure here. I didn't need to set up a web server. I didn't need to set up some third-party component to display this stuff. I have a visual representation of the timeline. But this doesn't really show off what I was talking about just yet because the file there, adding this the first time, is basically the same way as it's done in Git, just called code. So we open up VS Code and edit the file. There's nothing in here at all yet. So let's just go through. So we've got the changes saved. With Git, what you would need to do is add it. What's called staging. You stage the changes, and then when you go to commit the changes, it actually commits them. With Fossil, it just immediately recognizes that it's changed because the file already exists in the repository. It goes through and checks, like, is this one the same? Do I need to do anything with it? And just since it's changed, automatically knows that those changes should be committed. Now, this is the default behavior. It is still possible to do staging like with Git with Fossil. It's just that the default behavior is what at least HIP believes is the more common case. And at least with the way I develop, this approach is definitely my common case. Very rarely do I want to only commit part of what I've actually changed. So we can go through. And now remember, I didn't actually add this back or anything. So if I were to just commit that, like with Git, it would not have actually committed the changes made. And if we go and view the file for the specific check-in, you can see that it actually did automatically commit this. This is absolutely the single biggest reason why I prefer Fossil over Git and over most version controls. It might just be a way I do development. But overwhelmingly, the changes I make, I want to check them in all at once. I don't work on things unrelated to what I'm checking in. If that makes sense, I rarely wind up ever having a need to do partial check-ins. I've done them twice. A lot of commits, easily 600 plus commits, I've done them twice. So to have something like this where the only time you're ever adding a file is when it's truly a new file is just a major help. Because I never wind up with situations in Fossil where I forgot to stage part of my commit and then have to make a commit almost immediately after going, oh yeah, I forgot to add these things. Here they are. Now the UI, the automatic web interface and the fact that you can actually very easily couple this into an existing website using CGI. Just absolutely huge reasons why I prefer Fossil, along with, like I had mentioned, the fact that the repository and the working directory are separate. So in team scenarios, you can have the team share one repository and have several working directories from it. And then all the decentralized interactions that you need to can be done based on the different repositories for the different teams instead of a repository for every single developer. You can get this thing kind of set up with Git. Although Fossil has another concept that makes it quite easier to work with called Autosync, where if it's enabled, and I better remember where it was, Autosync. Yep, Autosync is on. If I were to check out from the repository I had set up and so on another machine, create a checkout based on this repository, we just set up here. If Autosync is on, what happens when you commit to it is it's also automatically syncs with the repository that it was cloned from. I meant cloned, not checked out. Checks out, sorry for working directories, I meant cloned. But it'll Autosync between the clones, which is extremely useful behavior in the typical way that at least I'm seeing things are done. I would absolutely love something like this to exist for Git because I've seen in all too often when I migrated my stuff over to Git, I will commit changes and totally forget to push them to GitHub. And so I can rack up change sets. Two, three, I've seen six before. And be wondering why they're not showing up on GitHub. I have to realize that, oh yeah, I didn't sync those as well. Now a lot of editors will have a commit and sync or commit and push button that you can press, which helps if you're using that specific editor but doesn't help if you're using the command line. And it's sort of a hack around a feature that Git would benefit from but just doesn't have. Now there are more technical matters as well for why I prefer Fossil over Git. Like I had said way earlier, Richard HIP has a great presentation on this. Then I will link to that down in the video description. Definitely check that out. It goes into considerably more detail. I'm just talking here about my biggest reasons for preferring Fossil. Show roughly how things are done in Fossil so that you can compare, see kind of where I'm coming from. Yeah, the link for Richard HIP's talk will be down in the video description. Definitely check that out. There are a lot of technical reasons as well for why, like auditing purposes and stuff, why Fossil. I would say is the superior version control. Have a good one.