It's Called VaMP

August 23rd, 2021

For code that is important to you, for code worth reading and not merely executing, for code whose history and references are meaningful and whose authors you'll *want* to know, interact and work with, there is now VaMP. For all other code, there are all the other versioning systems and if those fully satisfy your needs, then enjoy them as they are and good luck to you.

VaMP provides a wide range of support for coding as an intellectual activity, from verifiable, indelible and accumulated history, authorship, readership and investment of trust to smooth exploration, pooling of resources and collaboration that may be as deep and intricate or as superficial and plain as those involved care to make it at each step of the way. All code and work in general is thus securely anchored in its context at all stages - the provenience as well as the accumulated history matters for any versioned product, whether code or anything else. There are hard, cryptographic guarantees on the full state of the codebase at any version but the value and meaning of these is derived, as it should be, from the expertise and reputation of those that issue the guarantees in the first place. And on this support of visible, verifiable and indelible history of activity, one's own reputation can be built and continuously accumulated so that no useful effort need ever be lost and expertise as well as usefulness can be more easily identified and rewarded at every stage.

For the concrete implementation of the above, VaMP relies on my previous regrind and updated implementation of old Unix's diff and patch as well as the full cryptographic stack that I had implemented for Eulora (a first version of which you can find discussed in the EuCrypt category). VaMP is based on Mircea Popescu's design, hence the MP in the name. And since it was the infuriating broken state by design of the V tool that made me start the work on this in the first place1, I'm preserving it as the first letter in VaMP's name, to acknowledge that the experience of using V provided indeed the perfect help and motivation to finally move away from all its misery.

As to how VaMP works in practice, the short of it is - very smoothly and extremely usefully indeed! It's a pleasure to have it produce patches and signatures, check signatures, find and apply the relevant patches for any given task and even create essentially "branches" for exploring some changes to the code, all from one single command line tool and without the need for any additional scripts and hacked "a" "b" or hidden directories or whatnot. As a little but very helpful bonus on the side, it's even more satisfying to have it quickly check even a large legacy codebase and spit out neatly listed any and all broken bits and pieces that have to be fixed as a minimum requirement for the pile to be even considered worth looking at by a human eye. If you are curious, such broken pieces include all empty files and empty directories but also duplicate files and broken format files. And if you wonder "but how can it create the first patch, if it won't accept an empty directory as input", then rest assured that it's possible and otherwise keep wondering until you figure it out - it's good mental exercise! Or maybe start interacting and doing enough useful things so you get to the point where you may actually use VaMP and then it will all fall in place gradually and naturally anyway.

As a possible hint for the above mystery and to give one illustration of use, at least, note that VaMP can and happily does find precisely and exactly the relevant patches for a given task even out of a large pile of patches that might be related or unrelated to any degree. This is not by accident but a direct consequence of the fact that VaMP is by design a tool meant for real-life scenarios (these tend to involve people working on more than one project at times, go figure!) and a tool that works *for* you, not against you. As such, far from requiring that you mould yourself to fit computers' limitations2 what VaMP does is to harness the computer's resources for your benefit. In this specific case, what this means is that VaMP can indeed handle any pile of patches and never chokes on them no matter how related or unrelated they might be. It works correctly with any set of patches just as it works correctly with any graph that a pile of patches might make - the meaning of it all is very clearly, strictly and fully defined at all times so that one can even get a correct snapshot of *all* their codebases at the same time, shown side by side as either independent or connected trees (or even graphs, gasp!), as the case might be. Here's just one small example of the simplest sort (unconnected trees), from some of the initial test-uses (and yes, the first tree on the left is the one of VaMP itself):

vamp_1_640.jpg

In short and in conclusion, with VaMP, coding can be both fun and intellectually satisfying, once again. As it always tends to happen with any activity - it can become a pleasant thing to do indeed, but if and only if you have the correct tools and are working with the right people. And the two are more related than you think!


  1. In the end it didn't take 3 weeks but 3 months, all in all and even *all* considered (and there is, sadly, a lot more considered in there than was initially the case; such is life). To put this into perspective though, do note that it took as long as 6 years for v to not get anywhere past its broken state, it's an achievement of sorts, too. 

  2. In general, moulding to the computer's limitations happens every time when you have to look for a workaround to still achieve what you were trying to achieve in the first place when you hit some "can't do X" restriction. For example and taken straight from the V experience: you can't change a file back to a previous state because omg, the machine is confused and won't know how to order the patches correctly anymore. While V decrees in such situation that "you can't do that, you are also an idiot for wanting to do it", VaMP instead makes sure that the machine is *never* confused, that everything still works correctly in such a situation as well as in any other that might arise within the scope of the tool and then it lets you do exactly what you want to do, providing also full support to see exactly what you are doing.