What database table structure should I use for versions, codebases, deployables?

I'm having doubts about my table structure, and I wonder if there is a better approach.

I've got a little database for version control repositories (e.g. SVN), the packages (e.g. Linux RPMs) built therefrom, and the versions (e.g. 1.2.3-4) thereof. A given repository might produce no packages, or several, but if there are more than one for a given repository then a particular version for that repository will indicate a single "tag" of the codebase.

A particular version "string" might be used to tag a version of the source code in more than one repository, but there may be no relationship between "1.0" for two different repos. So if packages P and Q both come from repo R, then P 1.0 and Q 1.0 are both built from the 1.0 tag of repo R. But if package X comes from repo Y, then X 1.0 has no relationship to P 1.0.

In my (simplified) model, I have the following tables (the x_id columns are auto-in开发者_Python百科crementing surrogate keys; you can pretend I'm using a different primary key if you wish, it's not really important):

repository
- repository_id
- repository_name (unique)
... 

version
- version_id
- version_string (unique for a particular repository)
- repository_id
...

package
- package_id
- package_name (unique)
- repository_id
...

This makes it easy for me to see, for example, what are valid versions of a given package: I can join with the version table using the repository_id. However, suppose I would like to add some information to this database, e.g., to indicate which package versions have been approved for release. I certainly need a new table:

package_version
- version_id
- package_id
- package_version_released
...

Again, the nature of the keys that I use are not really important to my problem, and you can imagine that the data column is "promotion_level" or something if that helps.

My doubts arise when I realize that there's really a very close relationship between the version_id and the package_id in my new table ... they must share the same repository_id. Only a small subset of package/version combinations are valid. So I should have some kind of constraint on those columns, enforcing that ...

... I don't know, it just feels off, somehow. Like I'm including somehow more information than I really need? I don't know how to explain my hesitance here. I can't figure out which (if any) normal form I'm violating, but I also can't find an example of a schema with this sort of structure ... not being a DBA by profession I'm not sure where to look.

So I'm asking: am I just being overly sensitive?

Possibly you've normalized too far, would it not make more sense to have this structure:

repository
- repository_id
- repository_name (unique)
... 

version
- version_id
- version_string (unique for a particular repository)
...

package
- package_id
- package_name (unique)
...

Then have a table containing the valid versions and whether they've been released:

package_version
- package_version_id
- repository_id
- version_id
- package_id
- package_version_released
...

Thus the package_version table contains all combinations of all valid versions, as well as whether they've been released or not.
Unless of course i've missed something in your explanation above...

Yes, I'm being overly sensitive. Especially when I realize that a package could conceivably move to a different repository over time (changing the contents of the package table), so the package_version table doesn't really have extra information. In fact it's essential.