Remove references to duplicate_id where appropriate.

This field was mainly deprecated in a previous release.

However, from looking back, I can't see us actually doing a schema update when changing this functionality so attempt to tidy up now from history entries:

New Schema Updates:

Schema 204: Function - check duplicate ids. This looks for any bugs where duplicate id is >0. If it's found, we look for a relationship indicating the duplicate.  If found, remove duplicate_id from bug. If not found, check bug history table for th missing relationship link.
Note: If after this, the number of bugs with a duplicate_id is greater then 0, return a schema failure for now. We need to decide what to actually do here if a bug has a duplicate_id set, and there's no record of it in relationship or history tables.

Schema 205: Try to convert the old duplicate_id history field to relationship-duplicate fields. Look to see if bug_relationship exists, and if so, delete the duplicate id. After that, look for add/remove bugs.
Note: same logic here - if any else has gone on, abort the update so we can think about the data set :/

Schema 206: Remove obsolete duplicate_id field.

Note:
a) The above should only be a possible issue for old data sets [pre-dating 1.0.0] i.e. >12 year old instances
b) Part of the reason for trying to tidy this up is that bug_copy for one was still setting the the duplicate_id field even though we dont use it - therefore there is potential data in the field.
Only thing I would say is we should have same limit for both - that way it's easier to set up both editors and automated checks to enforce checking for example. 

Obvious values for line length that people seem to use is 80, 100, 120.

80 being the historical length due to what old PC's can support
100 seems to be the length that can fit side by side on a PC (not sure if it's just my box but if I make 2 notepad windows sit side by side, I get around 99 characters in each)
120 being the other limit

If you look around at the various frameworks, it looks to be around a reasonable split between 80/120 and 100/120. For example -

http://book.cakephp.org/2.0/en/contributing/cakephp-coding-conventions.html: "It is recommended to keep lines at approximately 100 characters long for better code readability. Lines must not be longer than 120 characters."

Symfony: http://www.php-fig.org/psr/psr-2/ [80/120]

Equally, you can see a rather length discussion between views @ http://stackoverflow.com/questions/903754/do-you-still-limit-line-length-in-code

I don't overly mind either way whether we say 80/120, 100/120 or 120/120. 

From a personal point of view, 100 works as I see 2x99 characters on  a widescreen. 120/120 is the "most editors can display at least one line, so set up your editor to display @ 120, and just stay within that always" option. Equally 80/120 works, but when I looked at the code base before, there were a number of places where lines/comments went over that but stayed within the 100.

In short - 80/120 or 100/120 ?