61–70 of 197 posts
Earlier quoted context omitted.
That's why Perforce is still the SCM of choice for a lot of creatives. I don't know if they still do it, but Unreal used to ship a Perforce license with their SDK.
That's also why perforce is slow as heck unless you throw massive resources at it. I also work in the chip industry BTW.
I love Git, but, then, I don't have a workflow that would benefit from Perforce.
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…
How is it not bad design? Let's say you are working in a team. Would you really want your colleagues spending a significant amount of time cloning your artifacts? Your comment is also not consistent with forgetting that one is not a developer. Even if it's my grandma, she's not gonna want to wait for 1hour to download a giant file from VC assuming she knows what a VC is. Large blobs can go into versioned object stora…
git has its place but it's really broken the world for how to think about SCC. There are other ways to approach it that aren't the ways git approaches it.
A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? 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 striv…
It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.
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…
It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit…
It's the same with Git. Don't put large files directly in Git because Git doesn't support that very well, not because it's fundamentally the wrong thing to do.
There should be a name for this common type of confusion: Don't mistake universal workarounds for desirable behaviour.
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…
I don't think that is true. You do see people warn that having large files in Git repositories, or any repository that wasn't designed with support for large files in mind, is "wrong", in the sense that there are drawbacks for using a system that was not designed to handle them.
Here's a historical doc of Linus Torvalds commenting Git's support for large files (or lack thereof)
Earlier quoted context omitted.
How is it not bad design? Let's say you are working in a team. Would you really want your colleagues spending a significant amount of time cloning your artifacts? Your comment is also not consistent with forgetting that one is not a developer. Even if it's my grandma, she's not gonna want to wait for 1hour to download a giant file from VC assuming she knows what a VC is. Large blobs can go into versioned object stora…
So how would you version a game that needs assets? These files must be versioned but can be very big, for example long cutscene videos. Some projects need the ability to version big files, there is a good reason why perforce exists and is widely used in the gaming industry.
When you want to do things that Fossil is not meant to do, then you're in trouble. I have no idea on how to do CI/CD and DevOps with Fossil and how to integrate it with AWS/Azure/GCP.
I find the whole ecosystem of Gitlab/Github, Notion, Jira and stand-alone alternatives like Gitea [1], Gogs [2], Gitprep[3] and others to be more flexible and versatile.
[2] https://gogs.io/
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…
Earlier quoted context omitted.
So how would you version a game that needs assets? These files must be versioned but can be very big, for example long cutscene videos. Some projects need the ability to version big files, there is a good reason why perforce exists and is widely used in the gaming industry.
I am not saying that it is a better UX, but hashed/versioned blobs on S3 would mostly work depending on tooling integration.