One of my current projects is yyj (for lack of a better name. It’s the archive file’s suffix.). It’s a file historian system. It disclaims any aspiration to be a version control system. It is primarily meant to be used by a single user.

The goal of the system is to efficiently maintain a history of documents. It is not based on a check-in model. Instead, the history is updated continuously in the background. If a file was saved every half hour, each update would be available without any intervention from the user.

It make use of the fact that .docx and .ods files are actually compressed with zip. I believe it would be efficient Java .jar files. It is optimized for XML files.

I’ve been using variants of yyj for many years and find it useful. The versions I’ve been using aren’t useful by anyone else because there is no UI. Variants have existed since 1989.

My inspiration for polishing it was listening to a student describe his Capstone project at IUPUI. He mentioned having to make copies repeatedly and struggle to keep the copies organized and up to date.

yyj would make that organization trivial. The student could retrieve any past version if it was needed. He would only need to save a single file to keep his work safe from software and hardware failures. Intermediate versions could be deleted when they aren’t relevant any more.

I think that if I succeed, yyj could be useful to very many people.