Quote:
Originally Posted by Starson17
IYou do realize that automerge settings already apply to CTL, don't you? Your scenario is exactly the type of thing that worries me, even though I did agree to make automerge apply to CTL.
|
Yeah I did know it is in there now, I'm just agreeing that it is the most dangerous aspect of it being in there.
At least when you add books from a folder, when you get that dialog telling you a book got merged if that surprises you then you have a chance to try to rectify it (well unless you had "overwrite" turned on).
Quote:
|
And it's also why I'm rethinking the application of Automerge to CTL. Its current behavior has always seemed a bit subtle and slightly dangerous. It was useful as the only automatic way to find duplicates, but that aspect of its usefulness is about to be superseded by Find Duplicates.
|
I guess the question is what behaviour will there be as an alternative? If I have a MOBI in library A and an EPUB in library B, then CTL with automerge is lovely jubbly. It's the overwrite/discard duplicate formats that are the "dangerous" ones imho. I guess we have to balance the complexity too if we try to get too funky with it
I guess there are other ideas I could throw into the mix as random thoughts. Like prompting the user during CTL when it detects there are duplicates and asking the user what to do (defaulting to your automerge settings but at least reminding the user what they currently are before doing damage).
When CTL/automerge creates a new book record from a duplicate, what date does it give it? The date of creating that duplicate new book, or the date it was imported into the original library? Just curious how "difficult" it would be for a user using "Find Duplicates" to identify which record is their original and which was from the CTL action.