Search current and parent paths for .tmsu like git searches for .git

[shabbyrobe]

I have a couple of pools of files that I'd like to tag using TMSU separately. I would prefer not to have to remember to alias tmsu -D each time I want to work on a specific pool. It would be awesome if tmsu ascended (or could be configured to ascend) from the current path looking for .tmsu directories like git does with .git. Would this be something you would consider including?

[oniony]

Great idea, I'll add this pretty soon. My only worry is its affect on performance: I'll have to run some metrics.

[shabbyrobe]

Maybe it could be off by default and enabled by a setting in ~/.tmsu.conf. Best of both worlds!

[oniony]

Yeah, that's definitely a possibility. I'll give it a crack and see how
well it performs before making a decision.

On Fri, 12 Dec 2014 21:02 Blake Williams notifications@github.com wrote:

Maybe it could be off by default and enabled by a setting in ~/.tmsu.conf.
Best of both worlds!

—
Reply to this email directly or view it on GitHub
#8 (comment).

[oniony]

Changes in b555621 and 822a3a4.

I was tempted to add an 'init' subcommand to create the .tmsu/db file in the current working directory but I changed my mind at the last minute. The reason for this is I need to get it clear in my head how it will work (especially when --database or TMSU_DB are used) and because I have an aversion to adding subcommands and really need to convince myself it's a good idea. For now I'll leave this as a manual operation but I may come back and add this later.

So, to create a new database local to a branch of the filesystem:

mkdir .tmsu && touch .tmsu/db

Or, to use (fork) your existing default database, e.g.:

mkdir .tmsu && cp ~/.tmsu/default.db .tmsu/db

I'll add something to the wiki about this.

[shabbyrobe]

Amazing! Thank you!

I've spent a bit of time with this over the last couple of days and I've hit a bit of a snag. I think this is just a case of my desired use case for TMSU not lining up with its intended use, but I'll outline it anyway just in case.

TMSU stores the full path to the file in the database, but this limits my ability to either share the database with others or to move it around on my own machine. It makes more sense with my desired workflow to store paths relative to the .tmsu folder, but I understand this limits the existing ability of TMSU to tag files outside a user's home directory.

One of the main use cases I have for portable, database relative tagging is for the various bands I play or have played in. We share huge collections of snippets and ideas and each band has a distinct set of members so I need one .tmsu folder per band. Being able to tag our snippets in a portable manner using TMSU is the killer workflow upgrade we've been desperate for. I would also like to use it for some photo collections, one private, one to share with my family.

I completely understand if this is not something that gels with your design goals for TMSU but I thought I'd just throw it out there anyway. Either way, I will still benefit massively from using TMSU as it is, but portability would be a very nice thing to have.

[oniony]

Great idea, thanks. I'll have a think about how this could work.

One thing to bear in mind with the current tool is that you can easily
rebase paths with the (relatively) new --manual option on the 'repair'
subcommand:

$ tmsu repair --manual /old/path /new/path

However I appreciate that's a workaround rather than a solution to your
problem which I will continue to think about.

Thanks,
Paul

On Mon, 29 Dec 2014 14:05 Blake Williams notifications@github.com wrote:

Amazing! Thank you!

I've spent a bit of time with this over the last couple of days and I've
hit a bit of a snag. I think this is just a case of my desired use case for
TMSU not lining up with its intended use, but I'll outline it anyway just
in case.

TMSU stores the full path to the file in the database, but this limits my
ability to either share the database with others or to move it around on my
own machine. It makes more sense with my desired workflow to store paths
relative to the .tmsu folder, but I understand this limits the existing
ability of TMSU to tag files outside a user's home directory.

One of the main use cases I have for portable, database relative tagging
is for the various bands I play or have played in. We share huge
collections of snippets and ideas and each band has a distinct set of
members so I need one .tmsu folder per band. Being able to tag our snippets
in a portable manner using TMSU is the killer workflow upgrade we've been
desperate for. I would also like to use it for some photo collections, one
private, one to share with my family.

I completely understand if this is not something that gels with your
design goals for TMSU but I thought I'd just throw it out there anyway.
Either way, I will still benefit massively from using TMSU as it is, but
portability would be a very nice thing to have.

—
Reply to this email directly or view it on GitHub
#8 (comment).

[oniony]

Relative paths idea moved to issue #15.