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

51–60 of 197 posts

Re: Fossil versus Git

#51

Post by ChrisMarshallNY »

iaresee wrote: post #38
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…

I did just over a decade in chip design. Versioning large files in that domain is commonplace and quite sane. It can take wallclock days of processing to produce a layout file that's 100's of MBs. Keeping that asset in your SCC system along side all the block assets it was built up out of is very desireable. Perforce handled it all like a champ. People who think large files don't belong in SCC are...wrong.

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.

Re: Fossil versus Git

#52

Post by toenail »

sausagefeet wrote: post #46
toenail wrote: post #7

Earlier quoted context omitted.

> Well, do you use GitHub or an equivalent? Not sure how that's relevant, but I have ~150 repos locally and less than 10 on github. I also like the unix philosophy of having tools that do one thing and do it well.

"One thing" depends on how you squint, though. If you view "version and track text information" then it makes sense to store tickets, wiki, code, yadda under the same tool.

I'm primarily a command line user, I don't use explorer to view, rename, move, copy files etc. Like I said, unix-y. If you think "manage computer stuffs" the OS should bundle all tools anybody could ever want.

Re: Fossil versus Git

#53

Post by gizmo »

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…

When you make a video game you want version control for your graphics assets, audio, compiled binaries of various libraries, etc. You might even want to check in compiler binaries and other things you need to get a reproducible build. Being able to chuck everything in source control is actually good. And being able to partially check out repositories is also good. There is no good technical reason why you shouldn't be able to put a TB of data under version control, and there are many reasons why having that option is great.

Re: Fossil versus Git

#54

Post by bradley13 »

Zababa wrote: post #29
otabdeveloper4 wrote: post #6

Earlier quoted context omitted.

Gitea is already "GitHub in a box". Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting.

> Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting. What do you mean by this? Having mostly used git and github, I don't really know what I'm missing.

Just a minor example that irritated me today: try to look at a graph of past commits. In GitLab, it is nicely presented. In GitHub, it is nearly useless.

Re: Fossil versus Git

#55

Post by firesteelrain »

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.

Then use a binary repository like Artifactory which has LFS support. You can still version them in git- just don’t store them in there

Re: Fossil versus Git

#56

Post by nightfader »

ChrisMarshallNY wrote: post #51
iaresee wrote: post #38

Earlier quoted context omitted.

I did just over a decade in chip design. Versioning large files in that domain is commonplace and quite sane. It can take wallclock days of processing to produce a layout file that's 100's of MBs. Keeping that asset in your SCC system along side all the block assets it was built up out of is very desireable. Perforce handled it all like a champ. People who think large files don't belong in SCC are...wrong.

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.

Re: Fossil versus Git

#57

Post by incrudible »

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…

> Would you really want your colleagues spending a significant amount of time cloning your artifacts?

Not just the artifacts, but their entire history. That is a problem that Git has out of the box, but there is no reason it needs to work that way by default. LFS should be a first class citizen of a VCS, not an afterthought.

Re: Fossil versus Git

#58

Post by bradley13 »

tecleandor wrote: post #10
bradley13 wrote: post #3

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.

Well, GitHub wiki is integrated too. https://docs.github.com/en/communities/documenting-your-proj...

GitHub is not Git.

Re: Fossil versus Git

#59

Post by ajb »

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…

This is an example of a more generic problem. We adopt some principle or practice for rational reasons, and then as a mental shortcut conflate it with taste, aesthetics, cleanliness. But no software or data is 'dirty' or 'ugly', we feel it so because of mental associations, but intuition is unreliable -the original reasons may not apply, or may be less important.

Re: Fossil versus Git

#60

Post by tom_ »

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…

The versioned object storage solves nothing. If your colleagues need the files, they're going to have to get them, and it's going to be no quicker getting them from somewhere else. Putting them outside the VCS won't help. (For generated files, you may have options, and the tradeoffs of putting them in the VCS could be not worth it. But for hand-edited files, you're stuck.)

If the files are particularly large, they can be excluded from the clone, depending on discipline and/or department. There are various options here. Most projects I've worked on recently have per-discipline streams, but in the past a custom workspace mapping was common.

Post reply on HN