This cmake file is mainly to make instal easy.

Of course, Python3 is interpreted, but I like having a nice cmake file
around to handle things like cleaning and packaging and the like.
Added initial version of ticket processor.

Although it doesn't do anything yet, already the initial framework for
the ticket processor lies plain, exposed by the magic of argparse.
Added ignore file with common extensions.

I need to ignore some files that are all generated. This ignore files
accomplishes that.
Added initial versions of ticket and init.

The basic execution flow is now handled by callbacks from within
argparse. We accomplish this by using set_defaults in subparsers to set
callback commands, then rely on the fact that only the main command
options, along with those of the selected subcommand, persist in the
finished args structure. Thus, only the set_defaults from the selected
subcommand remain, so only that func is defined.
Initial versions of basic ticket commands.

Stubs for the basic ticket commands are included in this commit. They
are literally copies of init. I'll differentiate them next.
Added initial descriptions to all commands.

I added initial descriptions to all commands, as well as replaced the
init strings with ones more appropriate. This stub now nicely shows you
which subcommand you are trying to run. Better, the help messages are
more meaningful, and now show the list of subcommands. I may also take
advantage of the aliasing commands to let subcommands have more than one
name, but we'll see about that.

The next step is to figure out the sqlite3 connection and get init to
prepare a not crappy environment for the other commands to work in.
After we have a working schema and an init that actually works, we
should be able to create the first actual tickets in the system!
Added new controller class.

The UI code shouldn't manipulate model objects, so we now have a
controller for that.
Adding basic sketches of index and ticket.

I am adding some basic sketches of the index and ticket model classes.
Tickets are very simple, and I suspect that the class is more or less
done. The index still has several factory methods and a pile of
accessors to implement, but we are well on our way there. Once the index
interface is more settled, I'll go ahead and start implementing the
DatabaseModel class, which hews to the same interface.
Added some functions to Ticket.

I added status flags and several methods to make merging and copying
Tickets easy. Now, the Controllers can simply reify Tickets, copy them
with edits, and merge the results, then tell index to update. Thus, we
can capture most of the easy commands with a simple workflow.
Added some comments.

I thought about how some of the methods could work. I wrote these
thoughts as comments. When I can get the network back, I'll look up how
to serialize and de-serialize objects in Python. It should be pretty
simple. Once I have read and write object methods, the rest should be
pretty simple. We can determine if the index has a ticket by trying to
get that ticket's ID's object. At the same point, that's also how we can
try to reify it. Only if that fails, in some cases, will we then try to
use the database to reify.
Added code to read and write index.

I decided to use shelve object persistence to model the index. Thus, the
index model is vastly simplified. This commit contains the code to
actually read and write tickets. I believe that, unit tests aside, this
section of code is now complete. As for testing, unit tests will be done
in python, and system and acceptance tests will be handled directly by
ctest. This way, I can put all testing under the aegis of a single make
target.
Started sketching out the controller.

I tried to sketch out the basic tasks that the controller should be
responsible for. I believe that, for the most part, a simple one-to-one
relationship between sub commands and controller task methods is
appropriate, with the odd exception or two.

As for the basic workflow model, Ticket will have two places where
tickets can reside: the ticket database, and the ticket index. The
database is modelled by DatabaseModel, and is responsible for the
long-term storage and querying of ticket information. The ticket index
is responsible for the temporary storage of tickets that are
works-in-progress. Whenever a ticket's state is changed, the altered
ticket is stored in the index. Only when the commit sub command is run,
does the ticket return to the database for long-term storage.

The main advantage for developing the system this way is the fact that
the editing commands need only deal with the index, which promises to be
speedy, rather than the database, which promises to never forget.
Merge ../ticket.old

Conflicts:
	.gitignore

Resolved the .gitignore to have both previous .gitignore files in it.