Version 1.7, alpha

After deciding to skip the 1.6 stable release, which would have had
only subtags, I moved on to add extended attribute support. I still
consider this release of TagFS to be in the alpha stage, however,
until more test code has been added for subtags and extended
attributes. At the same time, I have been using TagFS at this stage
for my own file management without incident.

Some utilities have been added for working with TagFS as well. I use
PCManFM for my file manager, and I find it useful to look at how a
file is tagged while browsing, so I wrote a module that will generate
a comma-separated list of tags in the status-line in the bottom of a
PCManFM window. There are also the tag (adds tags to files), ts
(like tag, but uses xattrs, and doesn't work on symlinks), and rt
(remove tag).

Version 1.6, beta, revision 2

Additional protection was added to close issue #31. Some
modifications were made to acceptance tests and test coverage
information is now being generated.

Version 1.6, beta, revision 1

This revision is just a minor correction to the formatting of the README.

Version 1.6, beta

Aside from a change in the database schema (the tag_union table was dropped
in favor of simply against file_tag), the changes were mostly internal to
TagFS. Issues #36 and #37 were fixed. This release also marks the beginning of
the first beta testing period for TagFS. The addition of subtags made a fairly
significant change to the structure of TagDB (the database that TagFS sits
atop) and saw some design changes in the way that subtags work, going from
being a much more ambitious tool from presenting related tags to being, as
originally intend, a simple means of separating distinct ideas that happened to
have the same basic natural character string representation.

This beta release is also a feature-freeze which I'll use to mark a change in
the release strategy of TagFS. From here on, testing and development will take
place on a 'development' branch. The system for version numbers will remain
the same, but alpha and beta releases will both be released in the development
branch and merged into 'master' only for full releases and bug fixes. Commits
published to GitHub on the 'development' branch will still only be tagged and
annotated (aside: version_1.6alpha2 lost its annotation, but the commit
message seems suffifcient so I've left it as is). This is mainly to maintain
master as a stable branch for new-comers who may miss my recommendation to
seek out a release.

Version 1.6, alpha, revision 2

Removed instances of inserting into file_tag with NULL tags (Closes #33)

• This change reduces database file sizes by as much as half by not
  storing the many duplicate rows that resulted from having a NULL-able
  primary key in the file_tag table.
• Added data and schema migration for removal of NULL tags. Incremented
  DB_VERSION.
• Moved files_by_id and loading from the sqlite database back into tagdb
• Stopped creation of log files from test_tagdb

Version 1.6, alpha, revision 1

The biggest user-facing change is that I reverted a change in lookup_file (part of TagDB) that made getattr on files very slow when looking up several files (e.g., when listing a directory). Also, I added a column to a table in the sqlite database, to upgrade an existing database, you can run the command:

$ sqlite3 <YOUR TAGFS DATABASE> "pragma user_version = 1;"

and then mount tagfs. Subsequent database changes which are compatible with earlier versions (i.e., that won't result in data lossage) will not require the sqlite3 step. Assuming you had a database formatted to work with version 1.6, alpha, that's all there is to it. Your database will be backed up and you will receive an error message if the upgrade does not succeed for some reason.

Version 1.6, alpha

With the addition of so-called subtags this is a step closer to Version 2. Aside from subtags, there have been improvements in the structure of the tag database and test code.

Version 1.5

TagFS now provides durability on most changes to metadata through the use of SQLite transactions. Creations, deletions, and modifications of the backing files are not atomic and TagFS will not make any attempt to detect or correct inconsistencies between the database and the backing files. Happily, only an uncompleted file create operation could cause a problem in file system operation (i.e., a 'ghost' file without data), and that is easily fixed by creating a file with the extra ID as its name in the data directory under 'copies'.

Per-file values for a tag, a feature which existed but could not be utilized previously, has not yet been added to the new SQLite database. Release 2 will probably see this functionality restored and made available. A script for migrating to the new database table structure should be provided.