On 23 Aug 2007, at 10:20 PM, Chris Goedde wrote: >> >> Probably the duplicates are not really duplicates, in that there is >> some difference. We check whether the standard fields (required, >> optional, or default fields) are the same to check for duplicates. We >> don't check the cite key. So it may also depend on how far they >> differ. Does checking for duplicates tell you anything? > > I'm not sure what you mean. After I do the merge, checking for > duplicates tells me that there are now 252 duplicates. What else is > it supposed to tell me? It seems that Bibdesk is merging the bib > files despite the fact that they are duplicates. Maybe I'm doing > things wrong? I'd be happy to email you the bib files if you want to > test them. >
Strange, it does check for duplicates, which I can verify with some test cases. If you can file me some files to test it I can have a look at it. >> There is no easy way to keep only one item if there is no clear way >> to know when they are equivalent. Somewhere you'll have to make the >> decision *which* item to delete, an automatic process could never do >> that without being arbitrary. > > Suppose that I don't care if it's arbitrary. My cite key system is > set up so that there is always a 1-to-1 correspondence between cite > key and publication. I'd be perfectly happy to arbitrarily throw away > all but one of each record with multiple cite keys. I don't suppose > there's an easy way to do that? > > Chris Currently there is no easy way to do this. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
