Why write yet another list manager?

Because I couldn't find any others that quite fit the bill. Every one of
the others I tried were either too complicated, too limited, or too tied
in to a particular methodology. Furthermore, most seemed to need an
Internet connection in order to work and relied on a third-party server
for syncing. I tend to be leery of such an arrangement.

The closest I came to a solution was Emacs's Org Mode. Unfortunately, I
was not particularly enthused by the MobileOrg app. Moreover, I found its
approach to syncing between phone and laptop rather clunky. And, although
I generally like Emacs and use it all day long on my desktop, Org Mode's
interface did not suit me.

Why is it called "Morg?"

Initially, I thought of calling it "Borg" because, well, you know, they
do bring order to chaos.

Then, as I am fond of recursive acronyms, "Mnorg" came to mind. It's a
play on Emacs's Org Mode and stands for "Mnorg's Not Org" (the "Mn" in
"Mnorg" is pronounced the same as "mnemonic," i.e., a silent "M").

In the end, I just dropped the "n." Think of it as a contraction of
"morgue," which gives the program a fitting, albeit cheesy, tag line:

Morg: Helping you stay on top of all the things you need to get and get
done before you end up in the morgue...

Using Morg

What all do I need to be able to run Morg?

You will need the following packages installed on your system:

Fossil

Python 2.7

SQLite 3

APSW

How do I install Morg?

For now, there is no neat package that you can install. Instead, you have
to check-out the source code, which requires Fossil to be installed on
your system.

At this point, you should have the Morg sources in ~/morg. Under
that will be a subdirectory named py, which has the main
program, viz., morg.py.

That's it: Morg is now installed and you can use it by running
~/morg/py/morg.py.

How do I use Morg?

At this time, Morg only sports a command-line interface. You can launch
it by running the morg.py program. Use the --help
option to get usage information. In particular, without any arguments,
Morg will drop you into interactive mode, prompting you to type in
commands until you exit the program.

You can use the help command to get a list of available
commands. Passing the name of one of the available commands to the
help command will print details about that command.

As these are early days, the only real command you can run is
new, which allows you to create new items and properties.

Eventually, Morg will have commands to search the database, edit items,
and to remove items and properties. Eventually, we will also build a
spiffy GUI for the application so you don't have to deal with the cryptic
command-line interface unless you want to run a quick query without
having to fire up the GUI.

Design and Implementation

Why are you using Fossil, an obscure version control system, instead
of something more well known like SVN, git, or Mercurial?

I wanted to be able to do initial development without the need for a
server. That pretty much ruled out SVN.

I am using git at work. While I appreciate some of
its features, I find it
somewhat
tiresome. When it comes to version control, I firmly believe that, like
plumbing, it should not stick out the walls. Put another way, I don't
want to be an expert mechanic and have a full theoretical understanding
of internal combustion engines to be able to drive my car.

While git may be perfect for the Linux kernel and other large projects
that have adopted it, it is overkill for Morg, which will never reach
that scale (in fact, I will probably be its only developer and user). So,
I wanted a simpler DVCS that would afford me the
luxury of ignorance.

the clean separation between repositories and working copies and
the fact that the entire repository is a single SQL database.

Fossil is certainly not perfect. Some annoyances include:

Confusing merge markers and lack of tracking merge conflicts to
serve as reminders in case they're not explicitly resolved. This
means you have to read the output of an update command very
carefully and remember the files that have conflicts because Fossil
won't keep track of that for you. Additionally, since there's no
explicit conflict resolution step, you have to clean up the
temporary files related to the merge conflict yourself.

No commit mails. The RSS feed doesn't quite work for me; I'd much
rather have an email show up in my inbox letting me know of commits
and other activity on a repo. Apparently, a hooks feature is in the
works; so this shortcoming may soon be a thing of the past.

The schism between what you can do using the Web interface and the
command line. Some features of the system seem to be accessible
only via the Web interface (e.g., amending check-in comments)
while others only work via the command line. In other words, the
software has two different and disjoint user interfaces, something
I find annoying and (for some reason) disconcerting.

The command set seems to be a bit of a hodge-podge. Shouldn't
open be better termed checkout? Is close
really necessary?

Minor bugs such as the inability to include enumerations in check-in
comments because lines with '#' in them get filtered out.

Sometimes, documentation can be a little thin and some of it is
downright confusing (what the hell does the second paragraph of the
help merge command mean?).

Despite these warts, all in all, I like Fossil. It doesn't impose an
undue cognitive load and allows me to concentrate on Morg development
instead of having to slow down to think about version control.

NOTE: If you like another version control system (SVN, git,
Mercurial, whatever), please continue to use it for your projects. I am
not trying to put them down in any way. I am only pointing out why I am
using Fossil for Morg. In other words, use what you like and don't tell
me about it; I don't care about your opinion.