31 ms·

Anu: A sound, distributed version control systema

166 points by lelf 6y ago

wocram 6y ago
Is there demand for this? Most real complaints about git are around scalability of giant monorepos, and a lot of work has gone into various solutions. The secondary complaints about usability seem to be papered over by popularity, and of course the relevant xkcd: https://xkcd.com/1597/ https://xkcd.com/1597/
- rudedogg 6y ago
  Take a look at https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html The patch model is simpler IMO
  - spockz 6y ago
    Wasn’t the patching fixed already with darcs and mercurial?
    - gwenzek 6y ago
      I don't think Mercurial is patch based. Pijul is more similar to Darcs. They claim to have a sounder and faster patch algorithm. And Anu is apparently even sounder and faster? https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
      - Aeolun 6y ago
        How can something be sounder. Either it’s sound or it isn’t.
      - pmeunier 6y ago
        Sounder, no. The theoretical complexity of Anu is improved compared to Pijul. The complexity of Pijul is in O(log l) where l is the number of lines written since the beginning of history, whereas Anu is in O(e) where e is the number of edits. Since each edit has at least one line, this is always better, and Anu can in fact handle large repositories (Linux kernel, Nixpkgs), that Pijul couldln't handle.
        samatman 6y ago
        Did you mean O(log e)?
    - cbzehner 6y ago
      My understanding was that darcs fixed the model but had fundamental performance problems at _some scale_. I think pijul took the same concepts and tried to streamline them. And this rewrite does that...again?
- miloignis 6y ago
  The site has https://anu.dev/documentation/why.html https://anu.dev/documentation/why.html For me, I'm excited about better, more rigorous merging and being able to cherry-pick & rollback changes without causing conflicts later on. (Cherry-pick in Git makes a new, unrelated commit, so merging with the branch you cherry-picked from can often cause merge conflicts, etc) In general, tracking and working with actual dependence between patches seems to open up more workflows, and less hacky ones.
- rakoo 6y ago
  My complaints with git are a bit different, having never felt the burden of giant monorepos (but it's definitely related) git was built as a tool for completely distributed source versioning, but most of us are using it in a centralized way. It's nice to be able to work offline, but when we need to synhcronize there's always a huge dance of fetching first, see if it has moved, merge/rebase, etc... git is good at storing what we did, but it doesn't help at all at saving what we are _doing_: all changes to the working directory are ephemeral, like files stored in ramfs. When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. Instead of having one server and a client, you now have 1 central server, 1 other server that only _you_ can access and will in practice contain 1 branch, and will be abandoned as soon as you're tired of it, and a client. Rights can't be managed at the branch level, so I'm just going to copy-paste the whole thing from the beginning of history and give it to you. What I would like to see in a VCS: - There is one central place where people coordinate - There is exactly one commit associated to a branch, and that association is the same on all machines at the same time (I don't want to git fetch) - If you want to do changes to a branch, you do a sub-branch - That sub-branch, along with your local changes in or out of the staging area, is synchronized to the server. If authorized, other clients can have a view of those as well It seems it already exists with fossil (https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#workflow https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#work...) and with older SCMs, although older SCMs are plagued with the locking problem. In a way the work that is done to handle giant monorepos is helping git move in this direction: all branches are automatically synchronized, and the vision with this kind of repo is that it's ok to commit often, even in small batches. But it's not quite there yet. I've read an account of how things are done in Google (https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) and it's closer to my dream system.
  - felipelemos 6y ago
    > When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. I believe this is more of a issue with GitHub then with git itself.
- astine 6y ago
  People definitely complain about merging difficulties with Git. The idea with Git is that the data model is simple enough that you can basically manually fix issues that come up. That unfortunately means that you have to take the time to understand Git's data model and not just memorize the interface and a lot of people have complained about that over the years. I think the idea with Anu is that issues don't come up in the first place and that it's hopefully more intuitive to use in the long run.
- alkonaut 6y ago
  I’d take a new git with just the UX fixed. If the underlying implementation of a new VCS is also better, that’s great, but my main problem with git isn’t that it’s not sound but that the UX is a steaming pile of legacy cruft, and it’s really more an API for version control than a polished interactive app for humans.
  - ptx 6y ago
    The OpenBSD developers are apparently working on something[1] like this. Another major focus seems to be privilege separation and security. [1] https://gameoftrees.org/ https://gameoftrees.org/
  - pmeunier 6y ago
    > the UX is a steaming pile of legacy cruft This is due to the lack of a solid theory to match the intuition. The "git way" of trying to match each use case is to add a new command for each new use case. I don't think you can fix "just the UX" without fixing the underlying algorithms.
    - alkonaut 6y ago
      As an example of the UX issue: just making command line switches consistent (e.g. delete always being the same switch) would be a very easy fix and a UX win, and it's only compatibility holding that back.
    - rkangel 6y ago
      > The "git way" of trying to match each use case is to add a new command for each new use case. To me, git's problem is the exact opposite - the commands are based on how the underlying technology works, not on the use case for the user. The best example is 'reset'. I understand git's internals reasonably well so I know the reason why, but it's not obvious that you need the same command to "un-add" a file, or to wind history back two commits.
  - sideeffffect 6y ago
    have a look at https://gitless.com/ https://gitless.com/ A talk introducing the issues with git and how gitless improves upon them https://www.youtube.com/watch?v=31XZYMjg93o https://www.youtube.com/watch?v=31XZYMjg93o
- yyyk 6y ago
  There's a lot of internet content praising git's 'simple immutable data tree structure' and how simple it is to implement. git's data structure is also the #1 reason behind limitations that many people try to bypass... e.g. giant monorepos weren't a problem even for ancient centralized VCs because these were file based, and if you wanted to work on a part of the tree it didn't matter - just push and pull the part you care about. But git has a data structure that forces everything in a single tree, so you have to use hacks (submodules etc.). Same thing for the much of the UX and the other complaints (changeset/patch model). When you get down to it, the data structure is behind 90% of difficulties with git.
bobuk 6y ago
For lazy people: Anu is Pijul (modern distributed version control system) rewriten from scratch, also with rust. It's on very early stage and now interesting mainly for academic/research.
- rudedogg 6y ago
  Is Anu GPL2 like Pijul? I can't find a license in https://nest.anu.dev/anu/anu https://nest.anu.dev/anu/anu. Edit: crates.io says gpl2
- nerdponx 6y ago
  So can I read Pijul repos with Anu and vice versa?
  - bobuk 6y ago
    It's rewriten from scratch and authors didn't answer about compatibility so I checked it right now. No, it doesnt' work with pijul repo at least in my scenarios
- glandium 6y ago
  So... pijul is dead?
  - dan-robertson 6y ago
    Pijul has been dead waiting for pijul 1.0 for about a year. People were already expecting the file format to change with pijul 1.0, however I think the name change was unexpected.
  - bobuk 6y ago
    It's like a zombie now, whole body is working but no brain activity at least for last 6 months.
    - keeganpoppen 6y ago
      this project would be what the zombies were working on, from what i can tell...
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
consultutah 6y ago
I’m excited to see there is still work being done on new VCS. Git will be hard to beat, but it looks like Anu is hitting on some of its weak points.
- minerjoe 6y ago
  > Git will be hard to beat. With the latest kurfuffle at Github, I've started moving to fossil. Having everything, wiki, pull requests, etc. as part of the repo is looking like a good move. Why let yet another corporation have control over something they should have never been given? https://fossil-scm.org https://fossil-scm.org
  - andrewzah 6y ago
    github != git ... I'm not sure why people strongly conflate these two so much. It would be equally as valid to self-host gitea/gogs/sourcehut/gitlab and/or an issue tracker of your choice, which arguably is preferable to adopting a completely different tool over what is a provider issue.
    - reificator 6y ago
      While that's a common conflation I don't think the GP was doing that. While I tend to self-host git, I can see the value they're claiming fossil has. Whether self-hosted git or hosting on Github, your issue trackers and such are typically separate from your main repository. Most platforms offer wikis as a side-by-side repository so that should be easy to move, but the rest is at the whims of the platform. The GP is claiming they moved to fossil because the one repository contains all of this data.
    - wtracy 6y ago
      I think minerjoe is trying to emphasize that fossil has all the features of GitHub included in the VCS itself, eliminating the need for any of the tools you listed above. I haven't followed Fossil, so hearing that it includes things like a wiki is news to me.
    - 6y ago
ComputerGuru 6y ago
The lack of a clear “why this rewrite was needed” somewhere accessible is a pretty big “f u” to anyone that evangelized for Pijul in the past.
- gwenzek 6y ago
  My uderstanding is that they wanted to change the algorithm and that the codebase needed a major refactoring. I think there was performance issues with the first implementation and design so they had to make very large change. https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451 https://discourse.pijul.org/t/is-this-project-still-active-y...
- Koshkin 6y ago
  > why this rewrite was needed We all know why
  - Ygg2 6y ago
    Why though?
  - hobofan 6y ago
    No we don't. Care to enlighten us?
    - bausano_michael 6y ago
      The new codebase is apparently in Rust. Perhaps the parent is being sarcastic with respect to the quantity of results here: https://hn.algolia.com/?q=rewrite+in+Rust https://hn.algolia.com/?q=rewrite+in+Rust
      - eikenberry 6y ago
        The old codebase was also in Rust. So I don't think this applies here.
    - FpUser 6y ago
gigatexal 6y ago
missing docs ugh
thewebcount 6y ago
I've been very disappointed with the pains of using git. I would really like something like this, but the steps to install it are: > Anu is written in Rust, and can be installed by first installing Rust, and then... Yeah, I'm not installing an entire language just to use your tool. I don't need to install a C or C++ compiler to run Photoshop or Microsoft Word. Why do I need to install a compiler, libraries, etc. just to try out your tool? No thanks.
- wtetzner 6y ago
  I mean, it's apparently still in alpha. I imagine there will be installers and it'll be included in package managers when it gets to 1.0.
- astine 6y ago
  Because that's traditionally how open source has been done? For decades? Especially if you're in a Unix/Linux environment? Eventually we started getting package managers and the distro maintainers started creating binaries of most of the packages you'd want to install, but the distro maintainers usually build those packages from source. This is new software and I imagine the distro maintainers will package it up if it starts to gain steam. Doing it from source also has the advantage that the package maintainers can customize the build process so that it works better with their system. Photoshoto and MS Word are closed source and proprietary, which creates issues if you want to package them.
thefurman 6y ago
Taking into account the history of how lines have changed isn't much better, sorry Anu. (Or if you think it is, please give some very compelling real world examples). I believe that you need to understand the semantics of the code to truly do what you are trying to do well, and for all other cases the snapshot model is more than good enough and given how we structure and modify code, it works out really well in practice. Code dealing with a single aspect should and almost always is co-located, so to get a conflict of intention in a merge is very rare. There are other human aspects like code ownership and collaborating teams which makes the issue even less of a problem.
- garmaine 6y ago
  I don't know about Anu (haven't looked at it yet), but with Pijul it would be perfectly possible to take advantage of semantic knowledge. Line-based changes is a default, but you could certainly apply file deltas based on a richer understanding of the underlying filetype.
  - dan-robertson 6y ago
    I’m not convinced by this but I’m also not convinced by the argument of the comment you’re replying to. The theoretical foundation Pijul/Anu works by starting with files as lists of lines (or some other thing) and patches as (injective) mappings from one list of lines to another which preserve the relative order between lines, then constructing the smallest generalisation of this structure to one where all merges exist and are, in some sense, well behaved. This generalisation is from lists of lines to partial orders of lines, where “B is preceded by A” becomes “A<B”. To do something similar with more structured files, one must find the corresponding idea to “a list of lines”, and this must work in a good way (e.g. changes like x -> (x); [a; b] -> [a] foo [b]; [[p, q], [r, s]] -> [p, q, r, s] must in some sense be natural operations in your structure (and diffs need to be reasonably easy to compute)). And of course it still needs to work in a sane way for unstructured data in big comments. Therefore I don’t agree that Anu would be easily generalised to this. I think this is basically impossible to do for situations where you want to capture all the structure (such that a patch to rename something merges well with other patches). I think it’s likely extremely hard for a part way solution. Finally I’m not convinced that the change would be that useful. Much of the structure of computer programs is implicit in the scoping rules in such a way that the “move blocks around” changes that line-based VCSes often struggle with will still be invalid with structural diffs.
gigatexal 6y ago
i can't get this to build on ubuntu for it not being able to find libssl
ChrisMarshallNY 6y ago
Good luck. I mean that. Git isn't perfect, but I've been using version control since Apple Projector (in the late 1980s), and Git has done the best for me. I've been using it for many years. I don't miss Projector one tiny bit. VSS (Visual SourceSafe) was a dog. It was direct file-based, and server connections would get very busy. It was the old-fashioned kind, with the need to check out files. But it had one very cool feature: You could create "aliases" of repo components; essentially creating a virtual repo that pointed into several other repos, taking just a couple of files from each. I could see how that would be a technical nightmare to implement, but I like it a lot more than "the whole kit & kaboodle" approach that Git takes. I also used Perforce for many years. It was a robust and dependable system, but had that need to check out files to work on them, and that drove me nuts. I like Git, because it is "team-friendly," and has a really light touch. It encourages many small checkins, which is how I think I should usually work. I wish it handled big files better, but that's not really a big deal to me. I think this might be why Perforce is still preferred for game development (their asset libraries get big). Oh, also Submodules suck like a supermassive, galaxy-core black hole.
- skissane 6y ago
  > I've been using version control since Apple Projector (in the late 1980s) Never heard of Apple Projector before. I've always been interested in the history of version control systems, so I would like to learn more about it. But when I search for the term, almost all I find is stuff about using projectors with Macs/iPhones/iPads/etc. Can anyone point to any information sources on it?
  - ChrisMarshallNY 6y ago
    Yah...you're right. I'll see if I can scare it up. It was integrated into MPW. UPDATE: It gets a brief mention in the "Legacy" section of the MPW Wikipedia page: https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop#Legacy https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works... It's obscure for a reason. It was the best back then, but was still a nasty bear.
  - karlding 6y ago
harikb 6y ago
I was hoping to get a vcs that distributes it files via sound
- rhizome31 6y ago
  And I was expecting version control for sound files.
  - AceJohnny2 6y ago
    And I was expecting sound version control for files
    - ben509 6y ago
      I'll file this version under sound control.
      - LkpPo 6y ago
        Your feelings about this version seem out of control...
        Zecc 6y ago
        I was expecting people making silly puns around the word "sound".
okokok___ 6y ago
https://nest.anu.dev/anu/manual https://nest.anu.dev/anu/manual This is returning "Not found" for me.
dan-robertson 6y ago
It seems this was posted very shortly after the webpage became live and that the website is probably not in a fully fleshed out state. Therefore it’s missing some details. Probably the website is mostly targeted at people who already know what pijul is. Here are some attempts at short descriptions of what I think this aims to achieve: - pijul 1.0. A stable repo format with performance problems resolved and a good foundation for further work - darcs except the algorithm is more convincingly correct and merges don’t take exponential time - A version control system where certain things behave in reasonable ways avoiding potential strange behaviour, eg it doesn’t matter what order you merge things in, you always get the same result. - A version control system that provides a good user interface to humans, a simple mental model, and asymptotically good performance.
chrisweekly 6y ago
Mods: "systema" title typo
agbell 6y ago
When I interviewed Jim Blandy, the creator of Subversion, he said one of his mistakes was trying to be clever with merges. In Git a merge is whatever you say it is and that is actually probably the flexibility that people what. Is that where the innovation is here, Darcs style patch sets?
- fanf2 6y ago
  Do you have a link to that interview? It's surprising to hear that svn tried to be clever with merges, because its merge support was no better than CVS until svn 1.5, which was released some years after git. (This is one of the reasons I went straight from CVS to git.)
  - gmueckl 6y ago
    SVN started to try to be clever with merges by tracking past merges between copies of files. This required tracking a lot of new information for each file. The developers used a combination of implicitly inferred merge history and annotations stored in SVN properties on each file for that. Combined with the fact that merge and commit were two separate steps in the workflow with manual conflict resolution in-between, this lead to sometimes severe usability issues. The merge would adjust the mergeinfo properties along with the files. Users would sometimes go and do svn revert on some of those files as part of conflict resolution. This would also silently reset the mergeinfo properties that were just updated. The current merge would still work out OK. But future merges involving the current branch or its descendants would get horribly mangled because SVN ends up applying sets of changes that are out of sync with the actual state of the files involved. That's part of what gave SVN its bad reputation.
    - ahaferburg 6y ago
      AFAIK the default use case is to only track merge info on the top level directory, as long as you only do branch/merge operations on the top level. By not doing that, yes, you can shoot yourself in the foot. But it's not necessary at all. Maybe we're talking about different versions, though. I used to use SVN 1.6+ IIRC.
Buttons840 6y ago
Why are they starting at version 1.0? A few months of public use might catch some important bugs before you commit to version 1.0.
- fabianhjr 6y ago
  This is techincally 1.0.0-alpha and it is a rewrite, by the same authors, of pijul that went from 0.1.0 to 0.12.1 during several years. The rebranding seems to be for several reasons including: - Breaking changes from pijul releases - "Quicker" writing of the command "anu" vs "pijul" (they also mentioned on Birdsite that anu is easier and faster to type on Dvorak) - Easier to spell out and pronounce vs pijul for non-latin-language-speaking users.
gnufx 6y ago
It would be interesting to have a comparison of the bases of this and Darcs3 (which is still in development). Hooray for work on patch-based systems anyway.
feanaro 6y ago
It's important to keep in mind that while the Pijul/Anu model brings many improvements over the git model, we still need to pair it with semantic merge algorithms if we hope to avoid nonsensical merges in the context of programming languages. Pijul/Anu alone cannot solve this problem.
- ricardobeat 6y ago
  Where can one find examples of that?
  - gmueckl 6y ago
    Plastic SCM is already at least partially aware of programming language semantics when diffing and merging. But that's a commercial offering (acquired by Unity recently).
  - feanaro 6y ago
    I'm personally aware of https://www.semanticmerge.com/ https://www.semanticmerge.com/, though I'm not affiliated and have used it only briefly.
  - gnufx 6y ago
    I can't remember for sure whether Toolpack's revision control component actually operated with ASTs, but I think it did. Certainly there was a semantic diff and patch. (Toolpack was quite an advanced a Fortran77 engineering tool set from the 1980s.) I don't know how general they could be, but darcs can have different patch types. However, the only extra one implemented, as far as I know, is token replacement.
some1else 6y ago
Author explains the state of documentation / mentions name change: There’s a frightening amount of stuff to write, and it will take me a while to explain everything. My current plan is, I’m actually releasing it as I’m writing this answer. There is almost no documentation, but I’ll write it one page at a time in the next few days. I’ll also write a blog post tomorrow to explain what I’ve been doing. Oh, and after talking to Florent, we have finally decided to change the name. More on that in my blog post tomorrow. https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451/49 https://discourse.pijul.org/t/is-this-project-still-active-y...
rkangel 6y ago
I still have the same question about Pijul/Anu that I had before: Can somebody give me a real world situation in which Anu would work better than git? The underlying model sounds like a big improvement, but I still can't map it to the benefit that I as a user would have.

166 points by lelf 6y ago

Is there demand for this? Most real complaints about git are around scalability of giant monorepos, and a lot of work has gone into various solutions. The secondary complaints about usability seem to be papered over by popularity, and of course the relevant xkcd: https://xkcd.com/1597/ https://xkcd.com/1597/

rudedogg 6y ago
Take a look at https://anu.dev/documentation/associativity.html https://anu.dev/documentation/associativity.html The patch model is simpler IMO
- spockz 6y ago
  Wasn’t the patching fixed already with darcs and mercurial?
  - gwenzek 6y ago
    I don't think Mercurial is patch based. Pijul is more similar to Darcs. They claim to have a sounder and faster patch algorithm. And Anu is apparently even sounder and faster? https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
    - Aeolun 6y ago
      How can something be sounder. Either it’s sound or it isn’t.
    - pmeunier 6y ago
      Sounder, no. The theoretical complexity of Anu is improved compared to Pijul. The complexity of Pijul is in O(log l) where l is the number of lines written since the beginning of history, whereas Anu is in O(e) where e is the number of edits. Since each edit has at least one line, this is always better, and Anu can in fact handle large repositories (Linux kernel, Nixpkgs), that Pijul couldln't handle.
      - samatman 6y ago
        Did you mean O(log e)?
  - cbzehner 6y ago
    My understanding was that darcs fixed the model but had fundamental performance problems at _some scale_. I think pijul took the same concepts and tried to streamline them. And this rewrite does that...again?
miloignis 6y ago
The site has https://anu.dev/documentation/why.html https://anu.dev/documentation/why.html For me, I'm excited about better, more rigorous merging and being able to cherry-pick & rollback changes without causing conflicts later on. (Cherry-pick in Git makes a new, unrelated commit, so merging with the branch you cherry-picked from can often cause merge conflicts, etc) In general, tracking and working with actual dependence between patches seems to open up more workflows, and less hacky ones.
rakoo 6y ago
My complaints with git are a bit different, having never felt the burden of giant monorepos (but it's definitely related) git was built as a tool for completely distributed source versioning, but most of us are using it in a centralized way. It's nice to be able to work offline, but when we need to synhcronize there's always a huge dance of fetching first, see if it has moved, merge/rebase, etc... git is good at storing what we did, but it doesn't help at all at saving what we are _doing_: all changes to the working directory are ephemeral, like files stored in ramfs. When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. Instead of having one server and a client, you now have 1 central server, 1 other server that only _you_ can access and will in practice contain 1 branch, and will be abandoned as soon as you're tired of it, and a client. Rights can't be managed at the branch level, so I'm just going to copy-paste the whole thing from the beginning of history and give it to you. What I would like to see in a VCS: - There is one central place where people coordinate - There is exactly one commit associated to a branch, and that association is the same on all machines at the same time (I don't want to git fetch) - If you want to do changes to a branch, you do a sub-branch - That sub-branch, along with your local changes in or out of the staging area, is synchronized to the server. If authorized, other clients can have a view of those as well It seems it already exists with fossil (https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#workflow https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#work...) and with older SCMs, although older SCMs are plagued with the locking problem. In a way the work that is done to handle giant monorepos is helping git move in this direction: all branches are automatically synchronized, and the vision with this kind of repo is that it's ok to commit often, even in small batches. But it's not quite there yet. I've read an account of how things are done in Google (https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) and it's closer to my dream system.
- felipelemos 6y ago
  > When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. I believe this is more of a issue with GitHub then with git itself.
astine 6y ago
People definitely complain about merging difficulties with Git. The idea with Git is that the data model is simple enough that you can basically manually fix issues that come up. That unfortunately means that you have to take the time to understand Git's data model and not just memorize the interface and a lot of people have complained about that over the years. I think the idea with Anu is that issues don't come up in the first place and that it's hopefully more intuitive to use in the long run.
alkonaut 6y ago
I’d take a new git with just the UX fixed. If the underlying implementation of a new VCS is also better, that’s great, but my main problem with git isn’t that it’s not sound but that the UX is a steaming pile of legacy cruft, and it’s really more an API for version control than a polished interactive app for humans.
- ptx 6y ago
  The OpenBSD developers are apparently working on something[1] like this. Another major focus seems to be privilege separation and security. [1] https://gameoftrees.org/ https://gameoftrees.org/
- pmeunier 6y ago
  > the UX is a steaming pile of legacy cruft This is due to the lack of a solid theory to match the intuition. The "git way" of trying to match each use case is to add a new command for each new use case. I don't think you can fix "just the UX" without fixing the underlying algorithms.
  - alkonaut 6y ago
    As an example of the UX issue: just making command line switches consistent (e.g. delete always being the same switch) would be a very easy fix and a UX win, and it's only compatibility holding that back.
  - rkangel 6y ago
    > The "git way" of trying to match each use case is to add a new command for each new use case. To me, git's problem is the exact opposite - the commands are based on how the underlying technology works, not on the use case for the user. The best example is 'reset'. I understand git's internals reasonably well so I know the reason why, but it's not obvious that you need the same command to "un-add" a file, or to wind history back two commits.
- sideeffffect 6y ago
  have a look at https://gitless.com/ https://gitless.com/ A talk introducing the issues with git and how gitless improves upon them https://www.youtube.com/watch?v=31XZYMjg93o https://www.youtube.com/watch?v=31XZYMjg93o
yyyk 6y ago
There's a lot of internet content praising git's 'simple immutable data tree structure' and how simple it is to implement. git's data structure is also the #1 reason behind limitations that many people try to bypass... e.g. giant monorepos weren't a problem even for ancient centralized VCs because these were file based, and if you wanted to work on a part of the tree it didn't matter - just push and pull the part you care about. But git has a data structure that forces everything in a single tree, so you have to use hacks (submodules etc.). Same thing for the much of the UX and the other complaints (changeset/patch model). When you get down to it, the data structure is behind 90% of difficulties with git.

bobuk 6y ago

For lazy people: Anu is Pijul (modern distributed version control system) rewriten from scratch, also with rust. It's on very early stage and now interesting mainly for academic/research.

rudedogg 6y ago
Is Anu GPL2 like Pijul? I can't find a license in https://nest.anu.dev/anu/anu https://nest.anu.dev/anu/anu. Edit: crates.io says gpl2
nerdponx 6y ago
So can I read Pijul repos with Anu and vice versa?
- bobuk 6y ago
  It's rewriten from scratch and authors didn't answer about compatibility so I checked it right now. No, it doesnt' work with pijul repo at least in my scenarios
glandium 6y ago
So... pijul is dead?
- dan-robertson 6y ago
  Pijul has been dead waiting for pijul 1.0 for about a year. People were already expecting the file format to change with pijul 1.0, however I think the name change was unexpected.
- bobuk 6y ago
  It's like a zombie now, whole body is working but no brain activity at least for last 6 months.
  - keeganpoppen 6y ago
    this project would be what the zombies were working on, from what i can tell...

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

consultutah 6y ago

I’m excited to see there is still work being done on new VCS. Git will be hard to beat, but it looks like Anu is hitting on some of its weak points.

minerjoe 6y ago
> Git will be hard to beat. With the latest kurfuffle at Github, I've started moving to fossil. Having everything, wiki, pull requests, etc. as part of the repo is looking like a good move. Why let yet another corporation have control over something they should have never been given? https://fossil-scm.org https://fossil-scm.org
- andrewzah 6y ago
  github != git ... I'm not sure why people strongly conflate these two so much. It would be equally as valid to self-host gitea/gogs/sourcehut/gitlab and/or an issue tracker of your choice, which arguably is preferable to adopting a completely different tool over what is a provider issue.
  - reificator 6y ago
    While that's a common conflation I don't think the GP was doing that. While I tend to self-host git, I can see the value they're claiming fossil has. Whether self-hosted git or hosting on Github, your issue trackers and such are typically separate from your main repository. Most platforms offer wikis as a side-by-side repository so that should be easy to move, but the rest is at the whims of the platform. The GP is claiming they moved to fossil because the one repository contains all of this data.
  - wtracy 6y ago
    I think minerjoe is trying to emphasize that fossil has all the features of GitHub included in the VCS itself, eliminating the need for any of the tools you listed above. I haven't followed Fossil, so hearing that it includes things like a wiki is news to me.
  - 6y ago

ComputerGuru 6y ago

The lack of a clear “why this rewrite was needed” somewhere accessible is a pretty big “f u” to anyone that evangelized for Pijul in the past.

gwenzek 6y ago
My uderstanding is that they wanted to change the algorithm and that the codebase needed a major refactoring. I think there was performance issues with the first implementation and design so they had to make very large change. https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451 https://discourse.pijul.org/t/is-this-project-still-active-y...
Koshkin 6y ago
> why this rewrite was needed We all know why
- Ygg2 6y ago
  Why though?
- hobofan 6y ago
  No we don't. Care to enlighten us?
  - bausano_michael 6y ago
    The new codebase is apparently in Rust. Perhaps the parent is being sarcastic with respect to the quantity of results here: https://hn.algolia.com/?q=rewrite+in+Rust https://hn.algolia.com/?q=rewrite+in+Rust
    - eikenberry 6y ago
      The old codebase was also in Rust. So I don't think this applies here.
  - FpUser 6y ago

gigatexal 6y ago

missing docs ugh

thewebcount 6y ago

I've been very disappointed with the pains of using git. I would really like something like this, but the steps to install it are: > Anu is written in Rust, and can be installed by first installing Rust, and then... Yeah, I'm not installing an entire language just to use your tool. I don't need to install a C or C++ compiler to run Photoshop or Microsoft Word. Why do I need to install a compiler, libraries, etc. just to try out your tool? No thanks.

wtetzner 6y ago
I mean, it's apparently still in alpha. I imagine there will be installers and it'll be included in package managers when it gets to 1.0.
astine 6y ago
Because that's traditionally how open source has been done? For decades? Especially if you're in a Unix/Linux environment? Eventually we started getting package managers and the distro maintainers started creating binaries of most of the packages you'd want to install, but the distro maintainers usually build those packages from source. This is new software and I imagine the distro maintainers will package it up if it starts to gain steam. Doing it from source also has the advantage that the package maintainers can customize the build process so that it works better with their system. Photoshoto and MS Word are closed source and proprietary, which creates issues if you want to package them.

thefurman 6y ago

Taking into account the history of how lines have changed isn't much better, sorry Anu. (Or if you think it is, please give some very compelling real world examples). I believe that you need to understand the semantics of the code to truly do what you are trying to do well, and for all other cases the snapshot model is more than good enough and given how we structure and modify code, it works out really well in practice. Code dealing with a single aspect should and almost always is co-located, so to get a conflict of intention in a merge is very rare. There are other human aspects like code ownership and collaborating teams which makes the issue even less of a problem.

garmaine 6y ago
I don't know about Anu (haven't looked at it yet), but with Pijul it would be perfectly possible to take advantage of semantic knowledge. Line-based changes is a default, but you could certainly apply file deltas based on a richer understanding of the underlying filetype.
- dan-robertson 6y ago
  I’m not convinced by this but I’m also not convinced by the argument of the comment you’re replying to. The theoretical foundation Pijul/Anu works by starting with files as lists of lines (or some other thing) and patches as (injective) mappings from one list of lines to another which preserve the relative order between lines, then constructing the smallest generalisation of this structure to one where all merges exist and are, in some sense, well behaved. This generalisation is from lists of lines to partial orders of lines, where “B is preceded by A” becomes “A<B”. To do something similar with more structured files, one must find the corresponding idea to “a list of lines”, and this must work in a good way (e.g. changes like x -> (x); [a; b] -> [a] foo [b]; [[p, q], [r, s]] -> [p, q, r, s] must in some sense be natural operations in your structure (and diffs need to be reasonably easy to compute)). And of course it still needs to work in a sane way for unstructured data in big comments. Therefore I don’t agree that Anu would be easily generalised to this. I think this is basically impossible to do for situations where you want to capture all the structure (such that a patch to rename something merges well with other patches). I think it’s likely extremely hard for a part way solution. Finally I’m not convinced that the change would be that useful. Much of the structure of computer programs is implicit in the scoping rules in such a way that the “move blocks around” changes that line-based VCSes often struggle with will still be invalid with structural diffs.

gigatexal 6y ago

i can't get this to build on ubuntu for it not being able to find libssl

ChrisMarshallNY 6y ago

Good luck. I mean that. Git isn't perfect, but I've been using version control since Apple Projector (in the late 1980s), and Git has done the best for me. I've been using it for many years. I don't miss Projector one tiny bit. VSS (Visual SourceSafe) was a dog. It was direct file-based, and server connections would get very busy. It was the old-fashioned kind, with the need to check out files. But it had one very cool feature: You could create "aliases" of repo components; essentially creating a virtual repo that pointed into several other repos, taking just a couple of files from each. I could see how that would be a technical nightmare to implement, but I like it a lot more than "the whole kit & kaboodle" approach that Git takes. I also used Perforce for many years. It was a robust and dependable system, but had that need to check out files to work on them, and that drove me nuts. I like Git, because it is "team-friendly," and has a really light touch. It encourages many small checkins, which is how I think I should usually work. I wish it handled big files better, but that's not really a big deal to me. I think this might be why Perforce is still preferred for game development (their asset libraries get big). Oh, also Submodules suck like a supermassive, galaxy-core black hole.

skissane 6y ago
> I've been using version control since Apple Projector (in the late 1980s) Never heard of Apple Projector before. I've always been interested in the history of version control systems, so I would like to learn more about it. But when I search for the term, almost all I find is stuff about using projectors with Macs/iPhones/iPads/etc. Can anyone point to any information sources on it?
- ChrisMarshallNY 6y ago
  Yah...you're right. I'll see if I can scare it up. It was integrated into MPW. UPDATE: It gets a brief mention in the "Legacy" section of the MPW Wikipedia page: https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop#Legacy https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Works... It's obscure for a reason. It was the best back then, but was still a nasty bear.
- karlding 6y ago

harikb 6y ago

I was hoping to get a vcs that distributes it files via sound

rhizome31 6y ago
And I was expecting version control for sound files.
- AceJohnny2 6y ago
  And I was expecting sound version control for files
  - ben509 6y ago
    I'll file this version under sound control.
    - LkpPo 6y ago
      Your feelings about this version seem out of control...
      - Zecc 6y ago
        I was expecting people making silly puns around the word "sound".

okokok___ 6y ago

https://nest.anu.dev/anu/manual https://nest.anu.dev/anu/manual This is returning "Not found" for me.

dan-robertson 6y ago

It seems this was posted very shortly after the webpage became live and that the website is probably not in a fully fleshed out state. Therefore it’s missing some details. Probably the website is mostly targeted at people who already know what pijul is. Here are some attempts at short descriptions of what I think this aims to achieve: - pijul 1.0. A stable repo format with performance problems resolved and a good foundation for further work - darcs except the algorithm is more convincingly correct and merges don’t take exponential time - A version control system where certain things behave in reasonable ways avoiding potential strange behaviour, eg it doesn’t matter what order you merge things in, you always get the same result. - A version control system that provides a good user interface to humans, a simple mental model, and asymptotically good performance.

chrisweekly 6y ago

Mods: "systema" title typo

agbell 6y ago

When I interviewed Jim Blandy, the creator of Subversion, he said one of his mistakes was trying to be clever with merges. In Git a merge is whatever you say it is and that is actually probably the flexibility that people what. Is that where the innovation is here, Darcs style patch sets?

fanf2 6y ago
Do you have a link to that interview? It's surprising to hear that svn tried to be clever with merges, because its merge support was no better than CVS until svn 1.5, which was released some years after git. (This is one of the reasons I went straight from CVS to git.)
- gmueckl 6y ago
  SVN started to try to be clever with merges by tracking past merges between copies of files. This required tracking a lot of new information for each file. The developers used a combination of implicitly inferred merge history and annotations stored in SVN properties on each file for that. Combined with the fact that merge and commit were two separate steps in the workflow with manual conflict resolution in-between, this lead to sometimes severe usability issues. The merge would adjust the mergeinfo properties along with the files. Users would sometimes go and do svn revert on some of those files as part of conflict resolution. This would also silently reset the mergeinfo properties that were just updated. The current merge would still work out OK. But future merges involving the current branch or its descendants would get horribly mangled because SVN ends up applying sets of changes that are out of sync with the actual state of the files involved. That's part of what gave SVN its bad reputation.
  - ahaferburg 6y ago
    AFAIK the default use case is to only track merge info on the top level directory, as long as you only do branch/merge operations on the top level. By not doing that, yes, you can shoot yourself in the foot. But it's not necessary at all. Maybe we're talking about different versions, though. I used to use SVN 1.6+ IIRC.

Buttons840 6y ago

Why are they starting at version 1.0? A few months of public use might catch some important bugs before you commit to version 1.0.

fabianhjr 6y ago
This is techincally 1.0.0-alpha and it is a rewrite, by the same authors, of pijul that went from 0.1.0 to 0.12.1 during several years. The rebranding seems to be for several reasons including: - Breaking changes from pijul releases - "Quicker" writing of the command "anu" vs "pijul" (they also mentioned on Birdsite that anu is easier and faster to type on Dvorak) - Easier to spell out and pronounce vs pijul for non-latin-language-speaking users.

gnufx 6y ago

It would be interesting to have a comparison of the bases of this and Darcs3 (which is still in development). Hooray for work on patch-based systems anyway.

feanaro 6y ago

It's important to keep in mind that while the Pijul/Anu model brings many improvements over the git model, we still need to pair it with semantic merge algorithms if we hope to avoid nonsensical merges in the context of programming languages. Pijul/Anu alone cannot solve this problem.

ricardobeat 6y ago
Where can one find examples of that?
- gmueckl 6y ago
  Plastic SCM is already at least partially aware of programming language semantics when diffing and merging. But that's a commercial offering (acquired by Unity recently).
- feanaro 6y ago
  I'm personally aware of https://www.semanticmerge.com/ https://www.semanticmerge.com/, though I'm not affiliated and have used it only briefly.
- gnufx 6y ago
  I can't remember for sure whether Toolpack's revision control component actually operated with ASTs, but I think it did. Certainly there was a semantic diff and patch. (Toolpack was quite an advanced a Fortran77 engineering tool set from the 1980s.) I don't know how general they could be, but darcs can have different patch types. However, the only extra one implemented, as far as I know, is token replacement.

some1else 6y ago

Author explains the state of documentation / mentions name change: There’s a frightening amount of stuff to write, and it will take me a while to explain everything. My current plan is, I’m actually releasing it as I’m writing this answer. There is almost no documentation, but I’ll write it one page at a time in the next few days. I’ll also write a blog post tomorrow to explain what I’ve been doing. Oh, and after talking to Florent, we have finally decided to change the name. More on that in my blog post tomorrow. https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451/49 https://discourse.pijul.org/t/is-this-project-still-active-y...

rkangel 6y ago

I still have the same question about Pijul/Anu that I had before: Can somebody give me a real world situation in which Anu would work better than git? The underlying model sounds like a big improvement, but I still can't map it to the benefit that I as a user would have.