Once upon a time I used Git - local repository only - for keeping track of any work I did on large, unyielding and messed up code bases of all sorts as I explored them, trimmed them down and hosed them up on occasion. And before Git I used Subversion and before that I used CVS and so on the list keeps going, from one big system to the next, ever more polished in some ways and ever the same at core, ever "new" of the sort that brought its own learning curve and its own set of dependencies but ever old in its disregard for the user's machine (on which it would require all sorts of shit installed) and ever old in the underlying assumption that the user doesn't - and even shouldn't - care to own their tools but care instead to adapt to the tool, to effectively serve as guinea pig for whatever the tool - the master - may require.

With all the above, I gained at least a lot of experience using existing versioning systems I guess, but not much more. And as the gap between my computers' environment and those tools' expectations only widened in time, there came the point where I ditched all of them, unwilling to put up with their requirements even if it meant losing the usefulness I extracted otherwise from them, mainly with respect to maintaining a clear history record of my work and being able to move back and forth through it with relative ease.

While I never regretted not having Git or similar, it's the lack of integrated record while working with a large code base that bothered me quite a lot because it does hurt in all sorts of ways, from piling additional work on just to maintain otherwise a separate record to making it harder -as in more of a problem waiting to happen- to explore more radical trims to the code. The solution that currently works quite well for me is a basic set of scripts that allows me to use V in a more streamlined manner at development time: I've made a keypair just for code development¹, a "init" script that creates the genesis vpatch containing whatever code you point it at and a "commit" script that creates a fresh vpatch on top of whatever you set out for it. So for a grand total of 108 lines of .sh scripts (comments included!), combined on occasion with a few more commands directly from the console (mainly when wanting to rollback basically but making a script out of a single command doesn't quite make sense to me), I get to simply use what I already have installed anyway, namely a V presser, vpatch (with Keccak) and gpg².

Using the scripts to genesis ...the scripts themselves was a pleasure, at that. Here's from the README file, to have it plainly and otherwise head over to my Reference Code Shelf for the genesis itself:

1. Prerequisites: vdiff, gpg (with secret key for the user set in v_init.sh).
2. NB: DO change in BOTH scripts the name to match the gpg key you want used by the script!
3. NB: the scripts are blind beasts and don't check anything but plow on, so unless you want to obtain garbage: a. know what you're doing and run them in the correct order b. don't mess up their expectations (esp the contents of the a b directories).
4. There are 2 basic scripts:
   • v_init.sh - to be run only once, at the very beginning; this creates and populates correctly (with the newly made genesis vpatch + corresponding sig that it creates) the directories a, b, patches, .seals and .wot.
   • v_commit.sh - this assumes that all directories are in place already (esp a, b, patches, .seals, .wot) and that b contains the result of a *previous* press on which the new .vpatch is to be created.
5. Usage:
   1. To genesis some code:
      from the directory of your choice, run the v_init.sh script giving it as parameters: the name of the project (it will be used to name the genesis as projectName_genesis.vpatch), the name of the directory containing the code you want under control (if it's not local, you'll have to give the full path) and, optional, any number of files that are not in the directory previously given but you want included as well (usually this is manifest and possibly a .gpr file for my use)

      Example:
      sh v_init.sh vcodectrl vcode manifest

   2. To pack current changes to the code into a new .vpatch on top of whatever is currently found in the b directory: from the directory containing the a,b,patches,.seals,.wot, run the v_commit.sh script giving it as parameters the name of the project, the name of the directory containing the code, the name for the new vpatch (without the extension so without .vpatch at the end) and, optional, any number of files that are not in the directory previously given but you want included as well (usually this is manifest and possibly a .gpr file for my use).

      Example:
      sh v_commit.sh vcodectrl vcode added_readme manifest README

   3. To check the result:
      simply use your favourite V implementation to press to whatever patch you want from the patches dir

      Example:
      vk.pl f
      vk.pl p v testpress added_readme.vpatch

   4. To work on a previous version of the code and possibly branch from there:
      delete the b dir
      use your favourite V implementation to press to the vpatch of your choice from the patches dir
      make a copy of your newly pressed code base into the b directory
      simply work on your newly pressed code base and then use v_commit.sh whenever you want to press a new vpatch on top.

      Example:
      rm -rf b
      vk.pl p v newbranch vcodectrl_genesis.vpatch
      cp -r newbranch b

   5. To clean up *everything*:

      rm -rf a b patches .seals .wot

1. I don't even intend to ever make this public, it has no business out there nor any "identity" as such, it's just a part of a tool, nothing more. ↩

2. For lack of republican option for it, so far ↩