tux0r

Posted on Mar 23, 2020

Tired of Jira? Here's a pure POSIX to-do environment (versioned and awesome) or: A case for SCCS.

#productivity #minimal #tutorial #sccs

Hi! Missed me? Good!

As I'm working on improving some of my workflow, I noticed that, unlike other dev.to fellows, I haven't written about tracking your things to do here yet. Let me try.

Preface

If you work in a team of more than two people, you might have to use large, mostly web-based to-do trackers like Redmine, Jira or Trello. Now I agree that, once they're established in a project or even a company, they are hard to replace. But what about smaller projects or, even more important, what about trying to make the most of your existing environment before introducing more overhead than needed?

Luckily, we have two solved problems here. Storing todo lists is exactly what the Todo.txt format was made for (as sufficiently described by @cwardzala on dev.to). Todo.txt has the additional advantage of being editable with any text editor, including annoying ones (Visual Studio Code), old ones (TECO, EDLIN) and POSIX ones (ed, vi). I was considering to talk in lengthy detail about TECO here, but I decided to go full POSIX instead, as - if you're not on Windows or Plan 9 - you might already have (or be able to get) all the required tools right out of the box.

Goals

By the end of this tutorial, you will have a self-hosted versioned multi-user Todo.txt-compatible to-do list using nothing but POSIX commands and a cloud. Feel free to still not use it afterwards.

Requirements

You will need some things:

A shared hard disk or cloud storage (e.g. a NAS).
- Something like Dropbox, OneDrive, iCloud, nextCloud, Seafile, Pydio, Box, ... will do as well - I bet you already have one! (Addendum: As @ajnasz has (correctly) pointed out in the comments, some of these services cannot be self-hosted. I'll use Dropbox in my example below though.)
- This article will assume that the "hard disk" (or "cloud storage") is readily accessible from your file manager. If it is not, please connect first.
An operating system that is mostly POSIX-compatible.
- Windows won't work and Linux might have problems. Both macOS and illumos work just fine though.

Setting up the environment

A text editor

You probably already have a good text editor. The POSIX standard suggests that you use either vi or ed though. As Todo.txt is a really simple format that won't require any IDE magic, I strongly support these suggestions. Once you understood ed, you might even consider to use it for everything that does not require seeing the whole file at once.

Long story short: I'll use ed in this article to tell you to edit a file. Feel free to use Emacs or whatever instead. :-)

A version control system

But, but tux0r! Everyone uses Git now! Now I really don't want to start this war here. Anyway, let me remind you of the Goals again: Self-hosting one or more text files; do you really want to set up a Git server for that?

Enter SCCS, the standard POSIX version control system, the father of RCS, grandfather of CVS, first developed in 1972 - and, most importantly, file-based instead of project-based. A collection of separately maintained Todo.txt files is not a project, is it?

Already having SCCS

If you use a commercial Unix operating system, you might already have the sccs command. If you don't have either, we can change that. Note that the GNU CSSC tool, made for importing "old" SCCS histories into Subversion or something, does not work well as a SCCS replacement.

Installing SCCS

Some Linux distributions, like openSUSE, package either Jörg Schilling's version of SCCS or the complete set of schily tools which contains SCCS.

Building SCCS yourself

If your operating system does not package any of the above, you'll need to build the full schily tools suite yourself. This is a relatively straightforward process once you figured out how it works:

Download the latest Schily package.
Unpack the archive: tar xjf schily-*.tar.bz2
cd into the unpacked folder
If you're on Linux, first follow the instructions in READMEs/README.linux. Most Linux distributions alias GNU make to make which is not the best of all ideas. :-) (TL;DR: It might be a good idea to use ./Gmake.linux instead of make for the following commands.)
Run make.
If that failed, cd into psmake/ and run ./MAKE-all. Then try again.
Run sudo make install. Unless anything goes very wrong now, SCCS - alongside all other schily tools like cdrecord - will be in /opt/schily/bin/. You might want to add that directory to your $PATH. Follow your shell's manual(s) to find out how. (export PATH=/opt/schily/bin:$PATH is always a good start.)

Try the sccs command again. You should see something like this:

Usage: sccs [ -R ][ -r ][ -drootprefix ][ -p subdir ]
     subcommand [ option ...] [ filename ...]

basic sub-commands:
    sccs admin  create or administer SCCS history files
    sccs delget do a delta followed by a get
    sccs diffs  compare edited file with a version of an SCCS file
    sccs edit   get files for editing
    sccs get    retrieve a version of an SCCS file
    sccs help   print help for SCCS commands and error messages
    sccs log    create a changelog using SCCS delta comments

basic project oriented sub-commands:
    sccs add    add specified files on next commit
    sccs commit commit changes to project repository
    sccs init   initialize empty project repository
    sccs remove remove specified files on next commit
    sccs rename rename specified files on next commit
    sccs status show changed files in the project

    (do 'help sccs'         for a full list of sccs options)
    (do 'help sccs_subcmds' for a full list of sccs subcommands)
    (do 'help project_subcmds' for a full list of project sccs subcommands)
    (do 'help get_kywds'    for a description of recognized ID keywords)
    (do 'help prs_kywds'    for a description of recognized data keywords)

Now we're ready!

Putting the pieces together

Assume you have a team of three people, all of them accessing the same shared WebDAV folder, Dropbox or whatever. I'll name them Jack, Joe and Jill for no good reason at all. Here's a possible workflow:

Jack creates a new team todo file.

jack$ cd Dropbox
jack$ echo "Todo version: %W% (%G%)\n" > team-todo.txt
jack$ sccs create team-todo.txt

team-todo.txt:
1.1
2 lines
jack$

The file is versioned and holds the date, thanks to the magic keywords:

jack$ cat team-todo.txt
Todo version: @(#)team-todo.txt 1.1 (03/23/20)

jack$

Joe gets the file and checks his tasks.

joe$ cd Dropbox
joe$ sccs get team-todo.txt
joe$ cat team-todo.txt | grep Joe
joe$

Joe has nothing to do ... :-)

Now Jill wants him to. Bad Jill!

jill$ cd Dropbox
jill$ sccs edit team-todo.txt
jill$ ed team-todo.txt
25
a
TODO Joe, do your work. Duh!
.
wq
49
jill$

Checking in, Jill creates a delta file which contains all the changes.

jill$ sccs delta team-todo.txt
comments? Make Joe less lazy

Now Joe can check again:

joe$ sccs get team-todo.txt
joe$ cat team-todo.txt | grep Joe
TODO Joe, do your work. Duh!

Reluctantly, Joe begins his work. But he can see who was it:

joe$ sccs log team-todo.txt
Mon Mar 23 17:08:02 2020 jill
    * team-todo.txt 1.2
      Make Joe less lazy
....

May they live happily ever after.

Anyway, that's about it. Sadly, I cannot comment here anymore, but I hope that some of you can still learn something from this.

Like: Never be the Jill in your company... ;-)

See you around!

Top comments (5)

Sam • Mar 25 '20 • Edited

Interesting idea. However, I understand that git might be overkill, but you can set up a remote git repository without a full server... it can be done using the regular file-system paths or even ssh.

E.g.

mkdir /path/to/my-repo
cd /path/to/my-repo
git init --bare

Then for the client:

git clone /path/to/my-repo
# It can even be done via SSH:
git clone ssh://server-hostname:/path/to/my-repo

Alexandre Rousseau • Mar 24 '20

I agree that Git seem a bit too big to versionate todo.txt file and SCCS seem be the best tool for this case. But I think it's a bad idea to learn another tool when you already know how to use properly Git. Also, setup a Git server is really easy. It's even possible to use an FTP server as an Git hosting.

John Colagioia (he/him) • Apr 28 '20

SCCS was my introduction to version control, in 1997 at my second job. This was long after it should have been used at an organization like that (the code was twenty years old and they had scripts built around it) and probably long after I really should have been shown a version control system...