CollectionDB & ATF Handling

[Jeff Mitchell]

> This commit is poor, as we already have a method,
> CollectionDB::migrateFile( const QString &oldURL, const QString &newURL ).

No, it's not, as it is called under entirely different circumstances than 
migrateFile.  Only the name is similar, which I can change if it makes you 
feel better.

> Also, there have been numerous reports that users have lost collection
> statistics, and i can't see any other work on stats tables aside from your
> own.

People have been losing their entire collection statistics for months.  The 
only work I've done with statistics has been the above method, which is 
*never* executed if ATF is not enabled.  No one has ever shown a correlation 
between the work I've done and the problems they're having when ATF is turned 
off.  In fact, no one has yet to show me a correlation between ATF being 
turned on and any harm coming to stats, either.

> Since we are _once again_ so close to a release, please create an ATF
> branch to work on.  I have already expressed my thoughts on such touchy
> work so close to a release.

a) There is no need for a branch when none of my code is executed if ATF is 
off.  To the best of my knowledge (since I worked hard to make sure of this), 
every line of ATF-related code is protected by either checking to see if 
MetaBundle::uniqueId() is null (which it will be if ATF is not on), or 
checking AmarokConfig itself.

b) This work is not "touchy."  I don't know whether you consider it that 
because you don't understand it or don't care about it or don't like it or 
what, but ATF has been quite stable for me, and for the few people that I 
know about that have tried it (other than a crash that was fixed months ago 
that Ian pointed out that could occur with ogg files).  The problem is that I 
need people testing it (which won't happen if it's in a separate branch, 
either), which we've planned to make a push for after 1.4.1, to roll it out 
publicly in 1.4.2 if everything goes well.


--Jeff