While examining possibilities in the Native Shell thread, there was strong resistance toward using text-based files for the shell scripts despite there not being many version control systems for binary objects. This led me to a possible breakthrough that Meta is already working on called Sapling. It’s a client-side version control binary filesystem based on Mercurial.
Coupling this idea with the way BeFS can query already, SQL databases have some sort of transactional journaling to roll back partially executed activity that fails and how someone back in the Be, Inc. era came up with a SQL wrapper for BeFS (or might have), this has me wondering: how hard would it be to implement version control in the directory structure in a future version of BeFS?
One reason Sapling is undesirable for projects already open sourced is that only the client code is open sourced. One reason it is attractive is that Git is excessively complicated compared to Mercurial which Sapling appears to possibly be based on.
1 Like
Why not just use Mercurial, then?
I don’t understand the use of building this into the filesystem. What is the technical reason that prevents doing things from userspace without specific support from the filesystem? That’s where I would start if I were to build a new version control system (I won’t, I’m reasonably happy with Git).
Start from the user interface. How should it work for the user? Command line interface? GUI maybe? Integration in an IDE?
Maybe you want something like “every time ANY app writes ANYTHING to the disk, it should make a new commit”. Then, yes, you might need to do that in the filesystem (or maybe not, you could as well do it as an overlay on top of the filesystem with userlandfs).
It seems a bit weird to me to start from the idea of “let’s make version control a part of the filesystem just because it sounds cool”, which means all that code would have to run in the kernel.
So, you want BFS to become a Versioning File System? Some of the filesystems listed in that page do only snapshots, while others outright support file revisions. AFAIK though, only VMS and Windows provide graphical ways to interact with versioning file systems with revisions.
Thanks for your Wikipedia link. It differentiated between journaling filesystems and revisioning filesystems. I was confusing the two. I knew journaling filesystems were common but didn’t have a graphical interface and I wondered why.
@PulkoMandy
The EdenFS that’s being designed to use the Sapling version control system linked above, is likely to only work on Windows, Mac and Linux. After hearing about the kernel support needed to implement the idea as proposed, I think a version-control add-on for folders in Tracker would make more sense.
For what it’s worth, there is a versioning FUSE filesystem that uses Git already:
1 Like
Indeed! There’s also TrackGit which is listed on HaikuDepot also.
TrackGit is more of a way to provide a UI for managing Git repos inside Tracker, not a filesystem using Git itself.
Yes. I think having an integrated GUI that works on version controlled folders would be a better option since @PulkoMandy mentioned that a filesystem would be kernel code while the overlay/plugin for version control would be user-mode code. Plus making the version control independent of the underlying filesystem might be better in the long run. On Windows there’s Tortoise Git as a 3rd party add-on. I suspect that Meta’s solution might also be similar, albeit optimized to large repositories of non-text data files, for Sapling.
If you want a reference on integrating VCS into a file manager, KDE’s Dolphin is in Haiku Depot and has services for Git, Mercurial, Bazaar, and SVN.
Thanks, I’ll check it out!
Edit
Wow! It’s got a bunch of dependencies. I think I’ll stick with Track Git and see what it takes to modify it instead.
I wasn’t suggesting to use Dolphin for your idea, but just as a reference on how other file managers do VCS integration.