Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I would like to identify a simple, FOSS version control system for plain text do

ID: 661596 • Letter: I

Question

I would like to identify a simple, FOSS version control system for plain text documents.

For more complex (academic) writing, I happily use LibreOffice. But increasingly I find it convenient to write more simple documents (reports, presentations, lectures, note-taking, whatever) in Markdown, usually using ReText.

My goal now is to manage versions of these documents. A scenario might be: drafting a presentation --> "finished" version delivered at Event A --> now redrafted --> delivered at Event B --> now occasion C comes along, for which the Event A version is the better one --> pulled and drafted for Event C.

So, my requirements are:

version control (essential, obviously!)
Ubuntu/Mint friendly (PPA would be great)
easy tagging/commenting/labelling of "commits"
simple tag/label browsing
simple tag/label searching
simple "recovery" of previous versions
possibility of doing diffs
possibility of syncing to different machines
simple directory structure/hierarchy for docs

One obvious solution that I'm aware of would be to use Git to manage the version control (and a number of other write-ups on around the web). I'm not wholly averse, and have used Github casually both from Windows and Linux (Ubuntu, Mint) for some years. But the key word there is "casually" -- and it seems a bit of a sledgehammer-to-nut scenario.

(I have also seen the question about a "Document manager for paperless office", but that appears to go well beyond my needs.)

There may well be other options out there, and certainly there will be tools I have never heard of. Grateful for any help with this one.

Explanation / Answer

Yes, you should use git*.

Now let me explain why. Given the current (rather nebulous) set of criteria in your question the answer seems fairly obvious. If you knew any more, you wouldn't even be asking this question. You have already brought yourself to the edge of the cliff, now you just need coaxing to make the jump.

* Or bazaar, mercurial or other DVCS depending on the front end tooling you prefer, to be explained.
The current scene and some history:

There are basically three kinds of version control systems: distributed, ham-fisted, and tapped-out. Allow me to expand on that technical terminology and how each came to be and would apply to your situation.

ham-fisted

Notable entries*: CVS, Subversion.

Before DVCS systems took the world by storm, there were VCS systems. These could be characterized by a central repository/server and a star pattern of user-workspaces/clients. These were an indispensably valuable tool for keeping a team of programmers on the same page and even adapted themselves to other uses. A single programmer could work from multiple systems and play around with branches and tags. They saved many a day. But they were inherently clumsy. They make some simple tasks harder. First there was the overhead of setting them up, the need for a server and specific protocols to connect them. Then there was the pain of dealing with those times you did something wrong. Suffice it to say these would get the job done for your use case but would introduce trade offs making life more complicated.

tapped-out

Notable entry: RCS.

For when a "full blown" system involving servers and clients and authentication and all that jazz was too much to swallow, it was possible to use a pared down system that lived in its own little bubble. RCS did this by eschewing the idea of a repository and just versioning one file at a time. You had file.txt and sitting right next to it a file.txt,v that had the version history. You could instantiate it easily on a per-file basis and use a handful of simple tools to work with diffs, roll back time, etc.

Now before you say, "Ah ha, that's just what I was looking for!", please read on because this is not the easiest or recommended way to do this any more. Easy entry came at the cost of a low operational ceiling that is pretty much guaranteed to cramp your style sooner or later.

distributed

At some point a bunch of smart programmers decided they had had enough of the pain and said, "We are going to eat cake and have it too." Amazingly, they succeed and distributed version control systems were born. These systems combine the best of both worlds