1. 21

  2. 5

    In Alan Jude’s talk about advanced tricks with ZFS that I cannot remember the exact name for right now, he uses ZFS in order to treat his SVN checkout of the FreeBSD source more like git.

    1. 1

      This sounds interesting, I’d really appreciate if somebody found a link to this talk (I’m trying to find it as well, will post if I succeed)

      Edit: maybe it’s this (slide 19)? http://allanjude.com/talks/vBSDCon2015_-_Interesting_ZFS.pdf

      1. 4

        It’s this talk:


        And the section I’m thinking of starts here:


    2. 5

      This seems like misuse of tools to me, though. A file system is not a VCS, no matter its snapshot capabilities.

      Still really cool.

      1. 8

        The Golang devs really want this, a smarter filesystem. They don’t want a VCS. They begrudgingly used Mercurial and when everyone kept whining they even more begrudgingly moved to git. They have intimated often that they want neither git nor hg, but are stuck with git.

        They are not alone. Many, perhaps most devs hate babysitting a VCS. You want to be writing code, right? Not figuring out how to write commits, and commit messages, and rebase, and branching, and merging, and pulling, and updating, and pickaxing… It is not an unreasonable position that these things should be automated or abstracted away from the actual business of writing code.

        1. 9

          The argument to be made here is probably that the complexity of Git, Mercurial, and the like is (largely) inherent to the problem being solved, and not incidental. That, essentially, it is not reasonable to expect that the difficulties of managing collaboration of multiple people on a single collection of code be abstracted away.

          1. 5

            There is much improvement to what we can automate. For example, we could have regular automatic commits. Or, watch the filesystem and every save is an automatic commit. That would get some way towards what the Golang devs want. Branching could be “automatic”, as it was originally with bitkeeper, git, and Mercurial (i.e. branching by cloning, every time you copy the repo you already have a unique branch). Pushing and pulling could be a simultaneous “synch” operation, optionally automatically tied to some sort of CI to make sure the new synched state isn’t broken. Better merge algorithms and tools are possible, such as for example something like Semantic Merge which understands the syntax of what’s being merged (much better than line-by-line merging).

            My point is, people hate VCSes, and rightfully so. There’s much improvement to be had. We shouldn’t take the current state of git or hg as inevitable complexity.

            1. 2

              I always had the feeling that Darcs “it’s just patches” had a lot less complexity down the line, but still, it seemed to run into weird cases.

              And that’s - IMHO - one of the big problems there. All VCSes are fine until 5 developers enter a room and don’t work quite in the pattern you expect.

              1. 2

                It was my understanding that Darcs fixed the exponential-time merge problem. Is this incorrect? Or are you referring to other problems?

                1. 2

                  I’m referring to the “it’s all clean and simple two-way-merges until we have so many development branches open that the whole thing turns into a mess”-problem :). It’s not a very technical problem.

              2. 1

                I agree. My point was simply that full automation of the process is probably impossible.

                1. 1

                  Wouldn’t commit-on-save lead to code that doesn’t build being committed?

                  1. 1

                    Fix up your commits with squash or rebasing would be the norm in that case. I personally have run commit-on-save (and periodically) for projects that I had a lot of small performance improvements that I wanted to make sure didn’t introduce other bugs. Then with the magic of bisect you can find the bugs super fast (as long as you have good pre-commit hooks in place).

              3. 3

                ZFS solves snapshotting state, but it does not handle telling a story. Commit histories are almost as important as the code its self – knowing why a hack exists is one Git blame away.

                If nothing else, you’d need to pair a snapshotting filesystem with a code review system, then you’re back to needing to specify two revisions of a filesystem to diff.

                Git’s model, while meta-filesystem, is superior IMO. I could imagine marrying Git with something like ZFS, but the portability of the .git directory is pretty excellent as opposed to being locked to a single filesystem.

                1. 3

                  ZFS solves snapshotting state, but it does not handle telling a story.

                  I understand, but the kind of person who hates a VCS is the kind of person who does not want to read or write stories. And that’s perfectly fine. If you don’t want the feature, you shouldn’t have to pay for it either. I see a good chunk of VCS users also really dislike it, writing commit messages like “fixed stuff” or “changes” and never really wanting to take the time to understand branches, merging, and all that.

                  It should be an option to be able to code without a VCS but with the ability to roll back to any version and to share your changes. That’s all that some people want: code, not commits.

                2. 2

                  although these systems could use better default options so that people don’t have to spend time learning a workflow in an industry standard tool, there’s not much of a way to magically do version control, without telling the system what you’re doing

                  1. 2

                    You’re insane. Version control systems make collaboration manageable.

                  2. 6

                    Obviously. The analogy was only meant to better illustrate the features of ZFS. The author even says so explicitly:

                    Using ZFS as a replacement of Git for is probably not a good idea, but just to give you a sense of what ZFS supports at the file system level, let me go through a few typical git-like operations:

                    1. 3

                      Counterpoint: this would make for fantastic bin file version control. Say maybe you had a repository filled with 3d models for a video game. the file sizes would be large and the text diffs would be useless. ZFS snapshots would be a slightly more space-saving way to handle versioning assets like that than simply making archives or full filesystem backups. Granted, it’d most likely require a knowledgeable dev-ops on the team to make and maintain those snapshots unless there was a nice frontend for the artists to use.

                    2. 3

                      so, I may be old, but part of why I always thought CVS was weird was, coming from a OpenVMS background, I never really saw the point of having a separate tool to give you what the file system already does. I can imagine that this is similar to how the Golang folks want to avoid git too… a good portion of them have Plan9 experience, and we had Venti & Fossil on Plan9, so why have a separate tool? Deliver a vac of FS state as clones, just like we did on Inferno :D

                      1. 2

                        ZFShub, embrace!