Rules of control of promotion

If the rule "Contrôle qu'aucun fichier design contributeurs aux fichiers générés
susceptibles d'être distribués n'est manquant" is active, it is impossible to promote a program if you have modify a design after the generation. You Must promote the design even the new release is not in the gerated program.

This rule should take into account the date of the generation of the program


Dans le cas dun programme cobol, les designs contributeurs peuvent
avoir été modifiés depuis la génération. Une nouvelle génération dans l
environnement source ne donnerait pas la même généré.

Dans lenvironnement cible sil y a eu des modifications de design, je
suis sûr davoir un généré différent. Le fait de promouvoir les
dernières versions des designs massure de pas retrouver le même
généré ce qui est linverse du but recherché.

Les règles de contrôles de RPP sur les actions ne peuvent pas être
ignorées donc il est impossible de se servir de cette condition comme
avertissement pour lutilisateur.

Dans le cas dun design, le problème se pose aussi. Si je modifie un
segment V1 et je livre dans un stream. Un autre développeur modifie
dans une V2 une rubrique du segment.

Je devrais être capable de promouvoir uniquement les modifications de
ma V1 sans prendre en compte la rubrique modifié en V2.

La règle ce dessous devrait tenir compte de lhorodatage pour les
promotions, par contre elle me convient sur la distribution du
workspace vers le flux:

Contrôle qu'aucun fichier design contributeurs aux fichiers générés
susceptibles d'être distribués n'est manquant. Cette fonctionnalité
requiert au minimum la version 6.0.2 de Rational Team Concert
client/serveur avec le dernier niveau de correctif.

Serait-il possible de dupliquer cette règle pour les promotions pour qu
elle ne contrôle que les modifications de design en ne prenant compte
que les changeset antérieurs à la génération de l'objet ?