TMSU 0.2.0 released

26 views
Skip to first unread message

Paul Ruane

unread,
Apr 26, 2013, 2:51:15 PM4/26/13
to tm...@googlegroups.com
Hello!

I have just tagged and released TMSU v0.2.0.


The main feature in this version is support for 'tag implications'. This lets you set up tags to be automatically applied when you apply others. For example you could have 'hero' applied whenever you tag a file 'batman' and 'villain' whenever you tag 'the-joker'.

Release notes:
  • Added support for tag implications, e.g. tag 'a' implies 'b'. New 'imply' command for managing these.
  • Added --force option to 'repair' command to remove missing files (and associated taggings) from the database.
  • Added --from option to 'tag' command to allow tags to copied from one file to another. e.g. 'tmsu tag -f a b' will apply file b's tags to file a. ('tag -r -f a a' will recursively retag a directory's contents.)
  • Added --directory option to 'status' command to stop it recursively processing directory contents.
  • Added --print0 option to 'files' command to allow use with xargs.
  • Added --count option to 'tags' and 'files' command to list tag/file count rather than names.
  • Bug fixes and unit-test improvements.

Paul

Dieter Plaetinck

unread,
Apr 28, 2013, 12:52:06 PM4/28/13
to tm...@googlegroups.com
isn't the imply command a bit of an overcomplication? it seems simpler to just edit a config file to manage implications


--
You received this message because you are subscribed to the Google Groups "tmsu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tmsu+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Paul Ruane

unread,
Apr 28, 2013, 2:35:28 PM4/28/13
to tm...@googlegroups.com

Hi,

It would have to be a config file per database as each database may use a separate set of tags (tag schema). So it would make more sense for it to actually be *in* the database and in which case you would have to understand the schema of the database and use the sqlite tooling to edit it. (In fact, the same argument could be made for tag management: these could be manually configured in the database too removing the need for the 'delete', 'rename' and 'merge' commands.)

As it turns out, that is exactly where the implications are stored: in the database. And to save people the need to understand the schema and tooling there is a simple 'imply' command. You are obviously free to manually edit the database if you do wish.

Hope this clears up the thought process behind this addition. I think it adds a great deal of usability with very little extra code or complexity. You can even ignore the command completely if it does not meet your usage scenario.

Thanks,
Paul

Reply all
Reply to author
Forward
0 new messages