Hi Paul, Pamela,
I've been through as many variations as you might care to try. And for what it's worth Paul, I think you've got it right. Yes, you have to label the application project and the common project. You can share the common files, but it's more work yet.
For a while I thought that was a good choice. I would share the common library files I needed in a project, dragging the BunchOfControls.VCX into the SpecificProject's Classes subproject. This was good in that everthing needed to run the project is in this single Visual Source Safe project. Get latest in your SpecificProject and you get the latest common files and latest specific files in one gulp. The path you need in development is shorter--no need to reference the common folder. One problem I had with this was pathing to graphics and header files. Had I followed Drew Speedie's idea of using making picture properties ="file.bmp" instead of get typing file.bmp, it might have helped. Of course then the files wouldn't automatically be brought into the project either. Another issue is constantly finding files you need to share and then dragging them into the SpecificProject. It was a pain. So, after fits and starts with several projects that shared various resources, I'm sticking with the Common and SpecificProject Visual Source Safe (actually SourceOffSite) scenario. If you can be disciplined enough to label key points, in every project, you will have great ability to easily get at consistent code.
While we don't store data in Visual Source Safe, remember, the stuctures, views, etc. must be able to be recreated as well. We always store a data dictionary file, a GenDBCX file that can generate the DBC and all tables and indexes for each version.
If your common files rarely change, Pamela's suggestion would work fine. In my work, the line of demarcation is not usually so clear. I would prefer to take a few moments and label everything in a consistent way, then hope I can make the right decisions in 20 months to get some little fix to SpecificProject out quickly.

>Hi Paul,
>
>>>>It's "common" to all my other projects. It has in it, for instance, my base forms class library
>
>So I have the same question as Kevin. It seems to me that the base library versions and the application library versions would vary independently. If I declare a new version of SuperApp and I haven't made any changes in the base classes, then I won't declare a new version of Base. I will simply put a note in the SuperApp label that it uses version X.X.X of Base.
>
>pamela