SVN - Comment puis-je intercepter et modifier ou ajouter des fichiers sur pre-commit?

Question

D'abord tout ce que je ne suis cependant pas sûr que ce soit même possible, je dois savoir comment il peut être fait et sinon pourquoi pas?

Je veux créer une application C # qui fonctionne au moment approprié au cours du processus de validation d'un dépôt subversion (pré-COMMIT je crois) qui sera ensuite ajouter un autre fichier à commettre.

Par exemple, je fais des changements à Program.cs et main.cs, mais pas AssemblyInfo.cs. Je veux être en mesure de forcer un changement à AssemblyInfo.cs ou tout autre fichier pour cette question.

J'ai écrit une application console à l'aide SharpSVN qui a tiré sur le post-commit, qui a ensuite remplacé un fichier, mais cela a provoqué une augmentation du nombre de révision. De toute évidence, ce n'est pas idéal.

J'ai alors trouvé SvnLookClient au sein SharpSVN qui fonctionne sur pre-commit et ont commencé à écrire quelque chose, mais a frappé une impasse quand je me suis rendu CopyFromPath ne veut pas dire ce que je pensais:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

Sinon, je vais régler pour le faire en dehors de C #, mais idéalement, je voudrais le faire dans une application console C # pour que je peux dire à mon serveur de référentiel pour effectuer d'autres tâches comme en cours d'exécution dans les scripts de base de données, etc.

Answer 1

Vous ne devez pas modifier la transaction lors d'un script de crochet. Vous pouvez rejeter la validation avec un message ( stderr sera envoyé au client ), ou le faire dans un engagement distinct dans le post-commit.

[modifier] Je tiens à préciser pourquoi modifier les transactions est une mauvaise idée (svn-technique):

Le client ne sait rien à ce sujet.

À l'exception de « OK », « ECHEC » et la sortie stderr il n'y a pas de retour canal du serveur au client lors d'un engagement.

Lorsque le client engage ses modifications, et le commit est rapporté pour réussir, il marque son statut de fichier local et le dossier pour être en phase avec la version du référentiel [xyz]. Lorsque vous changez quelque chose plus tard, par exemple, ajoutez le fichier localement, il veut engager ces changements, mais ... Eh bien, vous pouvez essayer de savoir ce qui se passe, je me attends quelque chose le long de « erreur de contrôle » ou « fichier déjà ajouté » . En fonction du type des changements que vous auriez probablement pas de meilleure chance d'obtenir un WC de travail que par la suppression du dossier et faire une nouvelle caisse de la partie endommagée.

Ce fut la partie technique. Maintenant, le développeur côté: Tout d'abord, semble correctement fixation automatiquement les changements intelligents, mais il échouera, en raison du simple fait que si la source serait pré-calculable, nous ne devons laisser écrire par les développeurs. Vous voulez que vos développeurs de faire la bonne chose.

Cela fonctionne mieux par l'éducation: ils doivent savoir ce que la bonne chose est. De bonnes mesures pour les amener à savoir ce qui ne, en plus de la bonne vieille formation quel qu'il soit, en leur donnant des commentaires.

Un message d'erreur du serveur svn, un courrier automatisé après cassé construit ou tests unitaires, les résultats d'un outil d'analyse de code source statique, etc., peut aussi servir comme un bon outil pédagogique.

Je recommande l'utilisation continue l'intégration et la validation de la source y arbre. Cela présente les avantages qu'un développeur ne sera pas bloqué pour commettre ses changements après une longue journée de travail, mais vous savez toujours que l'état de la source arbre.

Et, maintenant je pense que tout ce que vous voulez essayer d'atteindre: La source arbre côté serveur doit toujours être « fonctionnelle ». Le problème est que même avec automatique de fichiers fixation, pre-commit tests unitaires, style et vérification que ce soit, vous, enfin, reste à vérifier si le programme fonctionne réellement, par le système d'essais de style ancien. Donc, fondamentalement, vous ne gagnez pas vraiment quoi que ce soit.

La technologie peut soutenir les processus, bien pensés outils prennent en charge si bien qu'à la suite de processus permet réellement aux développeurs de gagner du temps et de faire leur flux de travail plus simple. Mais la technologie ne peut généralement pas remplacer les processus, et il ne peut pas remplacer l'intelligence humaine (au moins pour l'instant). [/ Edit]