31–40 of 197 posts
I don't know Fossil. However, the first entry in the comparison table puts me off. "VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC" I don't want my version control system to be a wiki. Or a chat app, or any of that.
I agree. But tickets... maybe. Issues feel integral to a project. -- it's weird they depend on what server you put stuff on.
I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of no…
if you have large files in your repository, you have a design problem.
I love git and I find no reason to look for anything else. Most of the complains I hear from git is from people that could not learn its logic. I think a lot of things could be built on top of git.
Agreed. Over 10 years of development using Git and I perhaps ran into an issue like 10 times, which is once a year on average. I can't think of any other tool that hasn't given me headaches at least once a day. Git is actually remarkable tech and its unfortunate that the prevailing hivemind opinion is that its bad.
I don’t think that’s true. I think the hive mind is that it’s good, or many “haha sucks but I use it all the time.”
I work sort of near “data science” and there’s lots of no code/low code people wanting to do data science (or at least bill for it). And I’d say the hive mind in non-coders is that fit is bad. But I think that’s more related to all coding is bad and git is like step 1 to coding so it’s the first hard step they hit.
I don't know Fossil. However, the first entry in the comparison table puts me off. "VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC" I don't want my version control system to be a wiki. Or a chat app, or any of that.
Then just don't use those features. There is no performance price for it.
One of the nice things about Fossil having a ticket database is that you can use it as a distributed, version-controlled SQLite database to store anything. You can even use it as a JSON database if you want. And the forum, well, it's lovely to have it there even if you rarely use it. Because sometimes if you're working with someone else it comes in handy - some conversations really should be kept with the code.
I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of no…
if you have large files in your repository, you have a design problem.
Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that?
The major issue with big files is resources: storage, and network bandwidth. But for both of these it is the sum of all object sizes in a repo that matters, not any particular file, so it's weird to be harking on big files being bad design or evil.
Earlier quoted context omitted.
if you have large files in your repository, you have a design problem.
Not in gamedev where you can have hundreds of gigs of art assets (models, textures, audio...), but you still want to version them or even have people working on them at the same time (maps...). But that is a different can of worms entirely.
Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwi…
Perforce handled it all like a champ.
People who think large files don't belong in SCC are...wrong.
Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwi…
Other than that my bigger gripe is when I read something like this:
> Git strives to record what the development of a project should have looked like had there been no mistakes
Git does not strive to do this. It allows it, to some degree. This is not the same thing at all and is basically FUD. I would say the debate is ongoing as to the value of history rewriting. It's probably a tradeoff that some orgs are willing to leverage and Fossil is masking that they allow less flexibility in workflows as an obvious advantage, feels slimy.