Well..the recovery model is really irrelevant from a dev perspective. I suppose a simple recovery model would make it smaller but even then you could sometimes do something on your dev database that changes a whole lot of stuff and posiibly not recover from if you are using a simple recovery model.(I am not too clued up around the recovery models..just know that once logs more that the other.)
But we had this dev database that had a 580MB log file and the actual data file is approx 60MB)..tried to change to a simple recovery model but the log file was still approx 180MB in size...Thus I opted for the attaching process. Yup allways make full backup before attempting these issues..
The tr log is a circular file - free entries are reused when the file wraps round.
If the recovery model is not simple then entries will not be released for reuse until the log is backed up and the file will just keep growing.
Changing the recovery model will release completed entries for reuse but not shrink the file - dbcc shrinkfile will do this.
>> you could sometimes do something on your dev database that changes a whole lot of stuff and posiibly not recover from if you are using a simple recovery model.
Unless you have a recovery strategy implemented the recovery model won't make any difference to this - see point in time restore.
Apart from bulk operations the various models log the same amount - the difference is in when the log entries are reused.
See shrinking the transaction log in bol.
You will need to get the active entries to the start of the tr log to release the maximum space by a shrink.