Today, when using the vaulting feature, files are selected based on their archive type only, when vaulting is enabled for a project. I would like to see some other rules added to help control the vaulting process better.
1) Selection by file name/type (extension). We have automated operations that generate and store files (text and binary) in the repository. Some of the binary files need to remain in the database along side of the related text files, but other binary files can go straight to vault. Looking for a policy that lists file name masks that can control which files can be candidates for vaulting, outside of just the archive type.
2) Selection by age. Some of our binary files need to remain in the database for a selected number of days before they can move to the vault.
3) Selection by count: Keep a select number of the revisions of a binary member in the database, and archive the rest. For example, keep the last 5 revisions in the database, and move anything previous to those 5 into the vault. When revision #6 is added, revision #1 moves to the vault, when revision #7 is added, revision #2 moves to the vault, etc.
4) Selection by size. Any binary files > 5MB go straight to the vault.
5) A policy syntax that can perform all of the above, in combinations. So that I can say "I want the last 5 revisions of all .DLL and .LIB files in the database, and archive anything previous, PLUS, I want all *.ser files archived after 30 days, Any files that haven't already been identified as a candidate, that are > 5MB, go straight to vault"
Vaulting is a great feature, but we really need to be a bit more selective about how and when we migrate revisions. Today, we are vaulting manually based on date, but additional criteria would make the combination of vault and database much more flexible.
