Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to obtain an exclusive lock on some art assets while editing them, because there is no sane way to merge two artists' async edits.
The SOTA in this area is Perforce (https://www.perforce.com/products/helix-core), a proprietary system. From what my gamedev friends tell me, when Perforce works it's great, but it hits enough snags that you need a tools engineer to manage it and occasionally fix issues manually. Git LFS is an alternative, but my gamedev friends all prefer Perforce especially when working on team projects beyond like 3-4 people.
This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it).
Needing to figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it.
Still didn't quite solve the issue, but access to that repository was heavily controlled.
Git enthusiast would often tell you to do this separately with a submodule, and set permission on the version control forge software level (which means Gitea/Github private RBAC access to certain repos for cloning), sure, but that is also painful as hell.
But my point is that all of this is exactly by design from Linus Torvalds's need for Linux Kernel to replace BitKeeper. Git simply isn't the tool for everything, it was developed for a software project with liberalism in mind, but corporate stuff is monoculture and prefers proprietary, shut-in model, and the eat your own dog food mindset, and no wonder it is so painful to deal with.
That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
However combining some of the flexibility and workflows of git with the ability to deal more efficiently and effectively with large asset files is something that a hell of a lot game engineers would be interested in. And having the virtual checkout as a feature out of the box for folks used to half terabyte repo sizes is definitely a huge plus.
This announcement is definitely a big deal, and if the promises for lore actually measure up, we could be seeing the beginning of a switch over to open source version control for larger asset heavy games where git was still not a great fit.
Will be interesting to see what the public code hosting platforms do (github), and whether there will be any major structural changes to git (I'm thinking not likely). I wonder if Epic will make a play to take business away from github or gitlabs.
Git is bad at such volumes of binary assets, textures, models, sounds, etc.
If there is an asset that is updated very frequently in the early stage of development, you'll be charged for all the storage for the rest of the repo's life. That happens a lot in gamedev: most assets go back and forth early on but once it's done no one will touch them ever.
At my dayjob we used Git LFS for a bit, but foud it unworkably clunky - we eventually found it easier to just make a separate "LFS" repository and add it as a submodule to the main monorepo. Now we can rewrite the history of the LFS repo on an as-needed basis.
That's one of the features of Git LFS is separately managed storage and lifetime.
You are correct that GitHub does not offer that feature.
This is used so e.g. an artist gets a repo that contains sources for the art assets, while a programmer gets the same repo but instead of art sources, it downloads the already produced binaries. As a SE, you just want to build the code, and don't care about 800 GB of art asset sources.
1. Code - Git
2. WIP art, shared assets (logos, marketing materials, etc) - Google Drive (because things are often changing, getting passed around, etc)
3. Finished assets (PSD files you're done with, or you think you're done with) - SVN (because we wanted a log of who contributed to what, wanted artists to be able to pick up where someone else left off; having a log of who made changes to a given PSD)
4. Assets rendered out to PNG to include in the app bundle/publish to the static file servers - Git (because those files never changed after being published so the git history wasn't polluted with unneeded files)
I've also used LFS, which is... a fine workaround, but still not great. Users who don't have it configured can still commit binary blobs; users who don't have it configured will clone files incorrectly; if the LFS server is slow, unavailable, unreliable, then the system starts to behave oddly; you need a Git server that supports it.
It was a huge hassle to manage; having a system like this would have been a godsend at that company, and if I still worked there I would be spending all day importing our codebase and assets into it to see how well it works.
In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.
For example:
- p4 tracks file metadata of client workspaces on the server (sync'ed locally, opened for edit, file revision, etc) and uses this as the basis to avoid doing unneeded work. If this becomes desync'ed, a reconcile or force sync must be used. A reconcile can take hours, potentially days; it tries do detect file moves by default, so likely at least O(c^n) for some c>1. I have never personally seen a default reconcile operation _complete_ over any modestly large game code base, and in practice, people accumulate a litany of workarounds and scripts to fix this for themselves.
- Scripting p4 is a nightmare. Documentation is poor, schemas do not exist, and all the language-specific libraries are just thin wrappers over its C++ API.
- By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings. This works until you have a mixed-OS environment, and discover a part of the pipechain that _must_ have a certain style. There are various levers to pull to make this better, but I've yet to find something fool proof.
- By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited. This means, to avoid having to do this manually, every tool you use needs to be p4-aware. Or, you can turn this off, and choose to contend reconcile instead. (See above)
- Branching a modest game project, with, say, Unreal source code, can take hours. And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.
- p4 is licensed by the user-account. Every user entity in p4 not intended exclusively for performing backups and maintenance operations counts toward this, including users required to integrate with other services. Plus, often times, these integration users must have admin access to be useful. The security posture is horrific.This is why I wish more command line tools were split into a library that does most of the work and a cli module for purely user interaction. Parsing stdout seems so unnecessary and could be avoided if a program could simply import a library.
p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.
- The P4 cpp api was apparently designed before any modern Cpp std lib was available. And is at best archaic, and stringly to use.
- P4 encoding support is pain in the ass to configure. And ensist on adding or removing bom to files.
Well, it is intended to compete with Git for version control. It's just that Git happens to be so bad at some aspects of version control that it isn't used much in those cases.
There's no good reason that Git couldn't be good at versioning binary files, or splitting up large projects. I mean people have tried - there's LFS and submodules. It's just that those both suck balls.
I was kind of hoping Jujitsu or Pijul would take a stab at these major Git deficiencies but unfortunately it seems like they are content to do them as badly as Git does.
If perforce is the best there is out there for large binary asset management, then there is a blue ocean worth of potential improvement for git.
Perforce is a piece of crap, a relic of the 20th century that must die in a fiery inferno.
Edit: I do feel a bit uneasy about epic games, though.
Git-annex ?
How well does Mercurial work in this situation (or even Subversion, given that Perforce is non-distributed like SVN)?
Should coordination live in the VCS layer? That sounds like it creates more issues than prevents.
Thats not how everyone else works.
We're all using package managers to help with massive amounts of 3rd party dependancies (why are you version pinning in any place other than your repo, why arent you pulling updates through your repo and reviewing them)
We're reliant on tools like artifactory to make sure those depedancys dont disappear or are not corrupted.
We use yet other tools to manage our binary files (this tool would fix that).
Github, gittea, gitlab, bitbucket... have all added piles of tooling around git, that are grafted on around its short comings.
> It's crazy to me that nobody has made anything better yet.
Because our entire industry has fallen into the rut of "more tools", of stacking turtles (https://en.wikipedia.org/wiki/Turtles_all_the_way_down ) rather than fixing the real issues that hold us back.
> Although I could start that myself and yet have not.
Because unless your a Google or a Linus, no one is going to look twice at your tool for something that is this important. Im not even sure that epic games has the good will, or trust to launch this.
I am going to give them the benefit of the doubt and take a long hard look at it, but my optimism is tempered. But unless it offers a LOT more than git, the extra overhead (lacking IDE support, deployment changes and all the other tooling in GIT's orbit) it isnt going to be a worth while change.
Also git-lfs is a crutch that breaks more often than it works :/
(I agree though that for small game projects, git is mostly 'good enough', even without lfs).
For the longest time Git tools were really poor. In recent years there's a few ok ones, like Git Fork, though I wouldn't know if those tools scale to the level of a AAA team size repo and not fall over.
it's also tough when you have 1TB of data, over 1mm files and you might want to lock hundreds files in one go
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 10 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
From the documentation, it looks like Lore does a bit better in this regard:
Pushing 1 fragment(s)
Pushed 1 fragment(s), 124.00 bytes
Pushing a3f8c2d1... to branch main
Pushed revision 1 -> a3f8c2d1... to branch mainOne might reasonably think that about a number of git's rough edges, and one might be surprised at the reality.
Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but when they tried to do it, it was rejected by git's gatekeepers.
There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.
The objects are referenced by trees. A tree is just a directory.
The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references):
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Because it would be terribly in-efficient to have a bunch of loose objects, git periodically groups them together into packs. To save space, the objects are compressed against one another (delta compression) within the packs.
https://git-scm.com/docs/git-pack-objects
https://github.com/git/git/blob/master/Documentation/technic...
When pushing or pulling, the git transfer protocol basically enumerates what objects each side has so that it only needs to transfer the difference. On top of that, it delta compresses the objects on each side that aren't already grouped into packs against each other to save space.
https://github.com/git/git/blob/master/Documentation/technic...
Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!
But if you really want to know, it's all documented both in the git book and git documentation directory, both linked above.
(Caveat: I'm working from memory and surely got some detail at least slightly wrong.)
I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.
I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.
CLI output should be in plain language and omit or minimize unnecessary detail absent a -verbose flag - for example, I'm just not interested in how many threads something took unless I'm working on it. As a user, I want to be focused on the task I'm doing, not on the perfromance of the tool.
I’m starting to come around though. From a UI perspective it’s a major improvement on git. The branching workflow is something that has taken a bit to get used to though.
What I will say to that directly is that everyone's different and expecting a UI to match every user perfectly is unreasonable. I don't think it's fair to call output that's more verbose than you'd like "user-unfriendly" without qualifying who the user/s is/are.
The thing missing from most of the responses to this is: you can only get this information once. It's effectively impossible to have any of this information repeated -- you can't run it a second time with `--verbose`.
I don't mind things telling me what's going on, and git's push output is perhaps verbose, but not by a margin that causes me trouble. Maybe that comes with always running less than ideal hardware and having second rate internet connections. I want to know why a command took longer to run than I expected.
The git support for new employees drops basically to zero.
I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
gritzko@spot ~/beagle $ be get
19:07 get ?#0ac49e6a
16:58 post ?0ac49e6a#POST-018 put:/post: banner on stdout
19:07 new beagle/test/be-post-put-banner.sh
19:07 upd dog/INDEX.md
...more stuff...
19:07 del test/post/01-bare-msg/01.put.err.txt
19:07 del test/post/01-bare-msg/02.post.err.txt
19:07 get abc?4222dfabStill the porcelain is more like cold stainless steel
Or maybe try jj. Either is better than you using Git's raw cli as someone who doesn't really know or care how it works.
Git cli is very much made with rough edges and is generally expected to be in hands of an advanced user, these days lots of commands have been made simpler and stuff, but git cli is just still very raw.
Not saying Lore's approach is bad, but sometimes "worse is better".
Having this output is useful for when it does break and you need to copy-paste your terminal output to someone who does understand it to explain it to you or explain how to fix it, but you're correct that 90% of this is effectively debug output that is almost never useful or relevant.
In most cases I would say they should remove any output that isn't necessary, but given that some git operations can be extremely long-running it's beneficial to have some kind of output so the user knows what's going on.
Case in point, this is the output I get when I try to clone the Linux kernel:
Cloning into 'linux'...
remote: Enumerating objects: 11623749, done.
remote: Counting objects: 100% (396/396), done.
remote: Compressing objects: 100% (189/189), done.
Receiving objects: 1% (181683/11623749), 90.11 MiB | 19.17 MiB/s
Also, I assume you're not but in case anyone is interested in the answers to these questions:
> What the hell is "delta compression"?
The 'delta' is the difference between one thing and another - usually one version of a file and another. Git does some fancy thinking to figure out which files are which other files but with changes, so that it can store just the changes from one version to the next.
For example, a 100 KB file where we only changed 500 bytes ten times would be 1000 KB, but because Git can store the deltas from one to the next it can be 100 KB (the original) plus ten 500-byte changes, for a total of about 105 KB.
> Why do I care how many threads it's using?
Because it directly affects how fast the process works; using 16 threads is 16x faster than using 1 thread (on average). Git automatically detects how many CPU threads are available and uses as many as it can, but if it's being very slow you might look and see 'oh, right, this VM only has two CPUs'.
> What is an 'object' and what does it mean when it's 'local'?
Uh, this one is deliberately vague I guess. An object is a thing that Git keeps track of. Usually this will refer to a blob, which is 'a bunch of bytes that make up a file', or a 'tree', which is a list of files and other trees - basically a directory structure, or a commit's information, but anything that Git keeps track of is an object.
Local just means that you already have a copy on your system. in the 'remote:' line you see output from the other end (where you're pushing to), so that's the server saying that it's using the files it already has.
> What does 'pack-reused' mean?
To be efficient, Git can take all the 'objects' and smush them into one big packfile (rather than having to keep track of hundreds or thousands of separate files). Since Git keeps track of files based on their contents, two identical files are just stored as one copy referenced twice, so it's possible that the file that you're pushing already exists in a pack file and can just be reused rather than having to push another copy.
Don't be too hard on Lore.
I'm not just picking nits here. And this is not cynicism.
so there you go.
[0] https://en.wikipedia.org/wiki/List_of_minor_Star_Trek:_The_N...
It's more likely that they took advantage of some things in the license that you weren't aware of, since stealing would be illegal.
The comparison with perforce explains more
It is interesting that people are so cynical about Epic giving out free games. I get that people love Steam, but competition in the storefront market is not bad.
> Open-source the desktop client so the community can build on its full graphical experience, not just download it. An early desktop client already exists as a binary download, but it isn't open source yet — it depends on some proprietary components, including Epic's internal design system. We're working to make all of it available in the open so that the client can ship as source alongside the rest of Lore. Lore is an open project, so it is important that the desktop client — which will be one of the main ways many people will interact with Lore — is also fully open so that the community is free to review, extend, and shape it.
they do say they will open source it, but who knows:
"It isn’t open source yet—it currently depends on some proprietary components, including Epic’s internal design system—but we’re committed to open-sourcing it in the future"
I expect fully to mean fully, though.
>Lore, formerly called Unreal Revision Control, is the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators have been using it to version their islands. It is also seeing progressive adoption by internal Epic teams, and is being implemented as the backing store for UEFN’s cook pipeline, where it replaces traditional intermediary storage layers—eliminating redundant file transfers and significantly reducing the time between publishing changes and those changes being playable.
Surprised it is in Rust and not Epic C++ or Verse. I wonder why.
As for Verse vs Rust, Verse is used in UEFN experiences, but it is _far_ from any kind of production state. It's also intrinsically tied to UEFN. It's not like you can download a standalone compiler or REPL for Verse.
EDIT: and then an example for the merge stuff I couldn't find while typing before: https://mergiraf.org/ and HN discussion a few years ago: https://news.ycombinator.com/item?id=42093756
I'm trying to figure out what Lore can accomplish that git+LFS can't. I've read about big binaries chunking, native interface and permission, is there anything else? Weren't those problems already solvable in the git+LFS ecosystem?
It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small and didn't want to self-host ourselves, but it was a bit of a rickety experience. You had to register an Azure account in order to be able to access the service, and you had to ask support to modify things like triggers. Coming from the world of GitHub and other SaaS products, you could tell it was an attempt to retrofit an older model into a new skin.
The Git LFS path has some unofficial support as well, but you are on your own when things go poorly. Epic doesn't provide much help there.
Competition in this space is welcome, especially if they're planning to make it fully officially supported by the Engine.
I wrote about why merging files isn't as common in the world of game dev for folks coming from the world of text: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
I just took over a team that was using Git, and yes, I know it's everyones favourite VCS but for Games it's just about the worst thing available. I could measure art reviews with git in hours, now with perforce its seconds. I wish I was joking.
All the interesting tools that UE5 uses (Horde/UBA for a clean example) will require perforce.
but, Perforce hasn't done anything with its industry position. It's expensive as hell and they don't have operational costs related to hosting (you have to host it yourself, and honestly, for performance reasons you really want to- despite it being a real pain to maintain passed first install). There's some echoes of stuff they try but they have absolutely no solid direction and nearly everything they've been doing cuts against common sense or their userbase, while their core product keeps getting renamed but no actual improvements.
It's a lesson in how proprietary software is really a prison.
I wish I could use a better code review tool than Swarm.
I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
and I wish I could run a distributed storage backend instead of relying on a big fat SSD and journalled backups that can't be restored because licenses are tied to the IP address of the main server.
It's forgotten technology, and the company that operates it is a zombie.
Anyway it's probably fine software and I am genuinely going to give it a shot for a usecase I have involving large image files. But the LLM-generated docs don't inspire confidence.
[1] https://epicgames.github.io/lore/explanation/system-design/
[2] They literally have a section header "10.1 Revision state as a 320-byte fragment". The byte size isn't even relevant in the code as an implementation detail, much less belongs in a design doc. No one read this doc before publishing it.
On the flip side, I expect the project itself will be workable - well, assuming they're actually using it themselves! UE is a big pile of Stuff on its own, and Fortnite must have god knows how much additional crap in there, so if this is (or will be) their replacement for Perforce internally, then it'll be getting a good deal of testing. (If they're just chucking it over the wall, though... well, sheesh, you first...)
(Perforce is the standard thing for games, and pretty well it works too, and hopefully this will deliver it a well-needed kick. It was sold to private equity about 10 years ago, and it feels like they've been coasting ever since. (Perhaps users in other sectors are happier though?))
Oof. So this isn't compatible with any tools that move or rename files. I can't see how this will be acceptable for real-world use.
[1]: https://gavinhoward.com/uploads/designs/yore.md
[2]: My WIP VCS has been named Yore for at least two years; I did not copy Lore's name.
It also makes diffing hard, as well as diff viewing.
Back then I concluded that it will probably never be built because OSS projects don't need it. Maybe this is changing now as AI allows for larger OSS projects.
Count on it.
Perforce definitely needs a challenger. It is not the incumbent because it is particularily simple to use or administer. Git is actually way simpler when it comes to branching operations for example.
The reasons why p4 is often preferred in gamedev have already been mentioned in other comments: large project support, permissions, file locking and so on. Another key reason p4 is the king for Unreal dev is just how well it's supported inside the engine. Not perfect, but it's the best supported VCS because it's what Epic uses. Even the Git plugin is painfully unfinished, because Epic does not internally use it. So with Lore I expect them to give it first class support. I'd recommend Git a lot more if the support in Unreal was better.
(background; I've been in gamedev for almost two decades now, 2-200 person companies, every kind of engine and version control system. I prefer git where I can use it: for Unreal that means small projects and/or tech savvy team members. Pick the tool that is right for the job and the team.)
- Pachyderm (Go): https://github.com/pachyderm/pachyderm
- XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf
- LakeFS (Go): https://github.com/treeverse/lakeFS
- Oxen (Rust): https://github.com/Oxen-AI/Oxen
I guess with AI, anyone can vibe code a content-addressed, chunk-level deduped, versioning system in Rust these days...
But jokes aside, Lore seems really cool! What's interesting is the realization that different domains/industries have similar problems, but they don't seem to be cross-polinating. In this case AI and Gaming both need a storage system that can version control large binary files at scale. I think there's lots of opportunities to share ideas here, but perhaps the lack of idea sharing (currently) creates opportunity!
That already warrants different storage architectures.
There are some awkward workarounds (officially supported ones) which create a local server and you then merge with a remote server upstream, but as you might expect: its awkward and practically nothing supports the workflow.
I am not sure it is much of an issue to implement a centralised system to solve domain-specific problems that are caused by or are in the context of inevitable centralisation.
I can see a bunch of media companies liking this, maybe even small design shops. Quite a lot of CMS and change control work for media is not much more than asset management; version control is often a bit of an afterthought.
Web interfaces to this might end up interesting for non-profits and charities with significant media outreach.
> 3.2 Explicit non-goals¶
> Peer-to-peer decentralization. Lore is centralized by design. Two clients communicate through the remote, not directly.
Epic interviewed me asking all sorts of questions about my customers and use cases.
"Pagan" "Lore" lol Our site used to say "Folklore" at the top of projects.
They still don't really understand the customer or use case, so have fun.
Epic has also been working on this for longer than the three months your repo has been around. This is the launch of the open source project and independent GUI, but it was already integrated with their Fortnite game engine before now.
Your VCS repo is called "Artifact". It seems like a stretch to say that somebody using "Lore" is copying from you. Even if it were called "Pagan" that's still a stretch, but "Artifact" especially so.
I think a VCS written in Javascript is also inherently a nonstarter for any kind of production-grade use case. The idea that nobody else can make a gamedev-oriented VCS because somebody in the world made a little hobby project along those lines is frankly ludicrous.
(Granted, I'm not exactly keen to use Lore myself given the heavy signs of vibe coding throughout the documentation and repo. A vibe coded VCS is also inherently a nonstarter. Here I'm hoping some third party will come along and do VCS for gamedev right!)
I'd also add that there's some element of hypocrisy to criticising Epic here when your own marketing pitch is "I copied Git".
Lore is meant for situations where your repository is going to contain gigabytes of binary files, such as art assets for games. Git is technically great at everything but that, and even the external solutions for that situation still kind of suck.
Passing for now.
Looks very git-ish. But probably better equipped for large binary files.
echo "Hello, Lore" > hello.txt
lore stage hello.txt
lore status --scan
lore commit "Initial revision"
lore pushI also don't see any sort of GUI client? So the whole art team is going to have to get up close and personal with the CLI
I always wondered if a combination of a database to index assets and asset versions with the data being in S3 style storage would be better for game assets; code can be in Git. Then your workflows are easy to build on top of that.
They have probably enough _bigger_ projects that dogfoods it.
Missed opportunity for Lorehub.
I don't know a single AAA (or even AA) studio that hosts Perforce in Cloud at all.
Perforce usually starts out life in a gamedev studio as running on "a spare desktop" which then eventually gets promoted to a real server in a closet.
The most important thing for Perforce is disk, memory and above all: bandwidth (of those things and the network too!); it's also quite latency sensitive since all operations touch the server. So running it far away is never a good idea.
There was some complicated perforce architecture inside Ubisoft to account for this: AAA tends to involve a lot of co-dev studios, so the lead studio would get the commit server and others might get replicas (and you could feel to pain)- but all the perforce instances were actually on the same machines and would replicate to one-another anyway: each project was given a port for the perforce fleet. Really bizarre.
but, that's besides the point. Even the tiny studios run their own locally hosted VCS machines.
That would be very powerful for various use cases.
Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes
I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible idea to tie your software stack to Epic Games of all people, given their track record
Would love any feedback on it or contributions if people are interested :)
After tearing it apart for 2 hours - it seems like a solid beginning, but definitely not a fully-functioning product (especially on Mac, I hope it works better on Linux/Windows).
Disclaimer - I'm one of Diversion's founders.
No thank you.
You can trust Helix and Perforce because they have been doing this for decades, and this is part of their core business. You know they will keep maintaining the products for a while.
But for Epic, they could give up on this project tomorrow, and nothing will happen to their business. If anything, they'll get some dev resources back which helps their business.
It's like why anyone would trust Cloudflare to continue investing in EmDash over the long run. Cloudflare doesn't care about CMS. Their business is not providing the best experience for readers/authors/site owners. It's just a side hustle that is almost irrelevant to their business.
[0] https://github.com/EpicGames/lore/tree/main/docs/developing/...
[1] https://github.com/EpicGames/lore/blob/main/docs/developing/...
Perforce is a necessary evil in games. Git is simply not suitable. So this is already a huge win.
I main that Git is - at absolute best - simply mediocre. It's not a "good" VCS tool. It is merely adequate.
I would love to see Epic go for a full Git killer.
It looks like Epic has a created a virtual file system interface that is cross-platform. FRICKIN SWEET. This is a critical component to making a VCS tool that doesn't suck. And there has not been an existing open source solution to it.
If the roadmap's "Web client and code review tools" could replace gerrit for me, this would be a easy switch.
Moreover, it looks like they designed both the mutable store and immutable store to be able to easily store their state directly on an s3 like system.
There are a number of features that would greatly speed up CI/CD system operations I belive.
It’s like anything you do has to talk to the server
Even something as simple as diffing a file will just hang if there are server issues
A quickstart link is buried in there, and that's good, but the value of the product is multi-faceted and doesn't address data architecture only.
I have considered git many times but i have effectively one user and what I have now works. And I did not see any benefits in git for this use case.
Interesting to see where this goes.
Let's say I had multiple games installed, lots of videos downloaded, 3-4TB of data.
As someone who came from VFX I always found the way Git works to feel very limiting. I feel like it was one of those things that was just so much better than the previous option (SVN, etc) that it blewup without actually being ideal.
Helpful page that gets closer to the details
They need a FAQ entry "Why isn't Lore hosted on Lore?"
????