Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil versus Git

fossil-scm.org

Post reply on HN
Print view View original

71–80 of 197 posts

Re: Fossil versus Git

#71

Post by dognotdog »

Culonavirus wrote: post #35
mgaunard wrote: post #23

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.

Indeed I have 3D assets in this case. Would this be done differently in an enterprise that has all kinds of tools to manage specialty workflows? Sure. Do I want to spend my days configuring and maintaining some binary blob / LFS storage system? No.

I’ve migrated a lot of projects from fossil to git eventually, but I dare say they never would have made it that far, had I started out with more friction, including fighting vcs tools.

Re: Fossil versus Git

#73

Post by iaresee »

nightfader wrote: post #56
ChrisMarshallNY wrote: post #51

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 mean "massive resources" is just de rigeur across the chip industry now. The hard in hardware is really no longer about it being a physical product in the end.

Re: Fossil versus Git

#74

Post by mdgrech23 »

idiot900 wrote: post #72

If Fossil is so against deleting commits, what do you do if you've accidentally committed sensitive information that cannot live in any form in the repo?

That's a good point. Delete the repo and start over I suppose? W/ git wouldn't it possible to find and restore that info anyway? Guess it becomes what do you care about most at that point.

Re: Fossil versus Git

#75

Post by beebeepka »

mgaunard wrote: post #23
dognotdog wrote: post #2

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.

[flagged]

Re: Fossil versus Git

#78

Post by moojd »

Supermancho wrote: post #40

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…

I like that git allows rebase, as long as it is only done in prs or local. Rebase in the sheets, merge in the streets.

Re: Fossil versus Git

#79

Post by tom_ »

dwpdwpdwpdwpdwp wrote: post #43
prepend wrote: post #17

Earlier quoted context omitted.

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…

Source control is all about managing diffs. Large files are fine, binary doesn’t make sense. Most of the time binary file diffs aren’t human readable. I store binary files outside of git but keep build logs containing binary file CRCs on git

Most binary files that people want to store in a VCS are stuff like .psd, .xlsx, .docx, and the like - data that's created by people by hand, but not stored as text.

Re: Fossil versus Git

#80

Post by nirvdrum »

nightfader wrote: post #39
henrydark wrote: post #36

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…

In Subversion at least, you'd do a partial checkout. If you don't need a particular directory you just don't check it out. If you lay out your repo structure well there's no problem. It was incredibly convenient.

I've tried many different SCM over the years and I was happy when git took root, but its poor handling of large files was problematic from the beginning. Git being bad at large files turned into this best practice of not storing large files in git, which was shortened to "don't store large files in SCM." I think that's a huge source of our availability and/or supply chain headache.

I have projects from 20 years ago that I can build because all of the dependencies (minus the compiler -- I'm counting on it being backwards compatible) are stored right in the source code. Meanwhile, I can't do that with Ruby projects from several years ago because gems have been removed. I've seen deployments come to a halt because no startup runs its own package server mirror and those servers go offline or a package may get deleted mid-deploy. The infamous leftpad incident broke a good chunk of the web and that wouldn't have happened if that package was fetched once and then added to an appropriate SCM. Every time we fetch the same package repeatedly from a package server we're counting on it having not changed because no one does any sort of verification any longer.

Post reply on HN