Also, when you save your file, use 'Save As' and a new name so that you don't overwrite existing material. While this will add and extra SEQ file, the added file can be deleted at a later date. In addition, having a second file will allow the two files' file sizes to be compared.
Noel,
Using Save vs Save As -
I don't think your disk space needs to expand any more no matter which you choose, due to how RB saves files, and you don't need to clutter up your working folder with different versions.
Examples below using each option.
Save As - makes a new file. Previous file accessible and new file too. Uses twice as much space as the original file (unless other editing changed the size significantly).
Save - RB marks the original file as a Backup (using the same amount of disk space as if you left it there by using Save As) by renaming it with the .bak extension in a new location.
Then RB saves the new version of the file.
Therefore so far they both have the same space requirements.
Now if you save the file again; RB makes another backup with a datestamp and goes thru the same routine.
So you end up with a history of the song with dates. Using Save As takes a little more work to keep this history in order.
You can control how much disk, and how many versions you want RB to keep, so you also get the benefit of not forgetting about 4 versions of a song from last year consuming space; RB drops the oldest file in the backups if you haven't reached the number of revisions for a given song, but did push the max limit.
I think it's pretty cool and has been handy more than once here.
"I like how it sounded 2 weeks ago" .. OK .. open backup from 2 weeks ago ..
Images below are from machine I happen to be on .. the settings vary per machine
Anyway, taking a little time to set up your RB backup structure can remove the need for renaming and cluttering, and also limit the disk space used if you get lazy (or apprehensive) about deleting older projects/versions.