People should use the VCS that's appropriate for their project rather than insist on git everywhere.
A lot of people don't seem to realise this. I work in game dev and SVN or Perforce are far far better than Git for source control in this space.
In AA game dev a checkout (not the complete history, not the source art files) can easily get to 300GB of binary data. This is really pushing Subversion to it's limits.
In AAA gamedev you are looking at a full checkout of the latest assets (not the complete history, not the source art files) of at least 1TB and 2TB is becoming more and more common. The whole repo can easily come in at 100 TB. At this scale Perforce is really the only game in town (and they know this and charge through the nose for it).
In the movie industry you can multiply AAA gamedev by ~10.
Git has no hope of working at this scale as much as I'd like it to.
The above should work. But does git support multiple filters for a file? For example first the above asset split filter and then store the files in LFS which is another filter.
I hope this "new" system works but I think Perforce is safe for now.
Github/gitlab is miles ahead of anything you can get with Perforce. People are not just pushing for git because they ux of it, they're pushing git so they can use the ecosystem.
There’s nothing technically worse about perforce with regard to CI/CD, if that’s what you’re talking about, except that of course there are more options for git where you just click a button and enter your credentials and away you go. But that’s more a function of the fact that there aren’t as many options for perforce hosting and companies are more likely to host it internally themselves.
If companies are using perforce but aren’t running any CI/CD that’s because they’re lazy/small/don’t see the value.
Swarm feels like a minimal effort to me and just isn't as frictionless as GitHub. Id rather have Swarm than not, but it's not great.
Disagree. I really like the "de-facto standard" that git has become for open source. It means if I want to understand some new project's source code, there is one less hassle for me to deal with: I don't need to learn any new concepts just to access the source code and all the tooling is already right there.
The situation we have with package managers, dependency managers and package managers for package managers is worse enough. I really don't want a world in which every language or every project also comes with its own version control system and remote repo infrastructure.
It's only git which has this fractal feature set which requires expert knowledge to untangle.
If nothing else, you have to install it. There will also be subtle differences between concepts, e.g. git and svn both have versions and branches, but the concepts behave differently. I don't know about Mercurial, but I'm sure they have their own quirks as well.
Also, tooling: I have a VSCode plugin that visualizes the entire graph structure of a git repo really nicely. Right now, I can use that on 99% of all repos to get an overview of the branches, last commits, activity, etc.
If version systems were fragmented, I'd have to look for equivalent tools for every versioning system separately - if they exist at all. More likely, I'd be restricted just to the on-board tools of every system.
They’re similar in the UI but the underlying architecture is vastly different, to accomplish different goals - sometimes what you want is an entirely centralized VCS, decentralized VCS, or a mix of both.
As for the tooling, any decent IDE supports different systems equally well. With IntelliJ I can use Git, SVN, and even CVS through the same UI. But yes, VSCode plugin XYZ doesn’t.
I can't imagine living without that feature, but I also do a lot of OSS work so I'm probably biased.
And if you and another developer make conflicting changes while offline? What should happen when you return online?
E.g. with current svn you get the latest changes from the server, open a diff editor, fix the conflicts and then commit.
The only difference here between svn and git is that svn merges the 'commit' and 'push' operations into one, e.g. instead of not being allowed to push, you're not allowed to commit in svn if there are pending conflicts.
This would be the part that would need to change if svn would get a proper 'offline mode', e.g. commits would need to go into some sort of 'local staging queue' until you get internet access back, and conflict resolutions would need to happen on the commits in that staging queue. But I really doubt if that's worth the hassle because how often are you actually without internet while coding?
Also, designing around distribution meant that merges have to be fast and work well -- this is a problem that most centralised systems struggle with because it's not a key part of the workflow. Branching and merging are indispensable tools in version control and I'm shocked how long CVS and SVN survived despite having completely broken systems for one or both. Being able to do both (and do stuff like blames over the entire history) without needing to communicate with a server is something that changes the way you work.
My actual hot take (as a kernel developer) is that email patches are good, actually. I really wish more people were aware of how incredibly powerful they are -- I have yet to see a source forge that can get close to the resiliency and flexibility of email (though SourceHut gets very close). git-send-email has its quirks, but b4 honestly makes it incredibly easy.
(There's also the owning your own data benefits that I think often go overlooked -- reflog and local clones mean that you cannot practically lose data even if the server goes away or you get blocked. I suspect Russian or Iranian developers losing access to their full repo history because of US sanctions wouldn't share your views on centralised services.)
But git is likely to be appropriate almost everywhere. You won’t just use svn just for big file purposes while git is better for everything else in the same project
Well yeah because text files are small. Thinking text files are insignificant to games because they are small is a really dumb perspective.
> Yet still people try to use git for version control in game projects just because it is the popular option elsewhere and git is all they know.
Or perhaps it's because it works really well for text files, which are a significant part of most games, and because the tooling is much better than for other VCS's.
Fact is that code is only one aspect of a game project, and arguably not the most important. Forcing a programmer-centric workflow on artists and designers is an even dumber perspective ;)
> and because the tooling is much better than for other VCS's
...only for text files. For assets like images, 3d models or audio data it's pretty much a wasteland.
In games a lot of the tooling assumes P4 so it's often a better choice, on the whole, but if git and LFS was as widely supported in art tooling it would be the clear choice.
Which is kinda funny because most people use git through Github or Gitlab, e.g. forcing git back into a centralized model ;)
> People should use the VCS that's appropriate for their project rather than insist on git everywhere.
Indeed, but I think that train has left long ago :)
I had to look it up after I wrote that paragraph about locking, but it looks like file locking is supported in Git (just weird that I need to press a button in the Gitlab UI to lock a file:
https://docs.gitlab.com/user/project/file_lock/
...and here it says it's only supported with git lfs (so still weird af):
https://docs.gitlab.com/topics/git/file_management/#file-loc...
...why not simply 'git lock [file]' and 'git push --locks' like it works with tags?
I think we really need more development of format-specific diff and merge tools. A lot of binary formats could absolutely be diffed or merged, but you'd need algorithms and maybe UIs specific to that format - there is no "generic" algorithm like for text-based files. (And even there, generic line-wise diffing if often more "good enough" than really good)
I think it would be awesome if we could get "diff/merge servers" analogous to the "language servers" for IDEs some day.
The alternative of preventing complex merge situations in the first place through file locking is low-tech, easy to implement, and automatically works on all current and future file formats.
The problem was that the scene information was fundamentally visual (assets arranged in 3D space) so even a diffable text format wouldn't help you much. On the other hand, scenes are large enough that you often would want to work on them in parallel with other people.
I believe their first solution to that was the Asset Server that supported locking. But that still doesn't give two people the ability to work on a scene concurrently.
Eventually, some users went and developed a custom diff/merge tool to solve the problem.
https://discussions.unity.com/t/scene-diff-ease-your-sufferi...
I've never done exactly that but I have occasionally decided how information will be represented in a data file with merging in mind.
https://github.com/ewanmellor/git-diff-image/blob/master/REA...
Of course if you’re working with others you will want a central Git server you all synchronize local changes with. GitHub is just one of many server options.