Est-il acceptable / bon de stocker des fichiers binaires dans SVN?

Question

Nous aimerions partager les fichiers binaires du projet d'exécution. Ainsi, chaque membre de l'équipe pourrait utiliser la version de travail actuelle. Il est acceptable / bon de stocker des fichiers binaires d’exécution dans le SVN?

Answer 1

Les deux raisons les plus courantes que vous pouvez stocker des fichiers binaires dans un Système de Contrôle de Version sont:

• magasin de tiers externe des bibliothèques.
  Habituellement, on les stocke dans un repository Maven, mais à les stocker dans le SVN vous permet d'avoir un et un seul référentiel pour l'ensemble de vos besoin: obtenir vos sources, et obtenir vos bibliothèques vous avez besoin pour compiler les sources. Tout vient d'un référentiel.

• des livraisons aux magasins pour en accélérer le déploiement.
  Habituellement, les livraisons (l'exécutable que vous avez à construire à déployer en production) sont construits sur la demande.
  Mais si vous avez de nombreux environnement de pré-production, et si vous avez beaucoup de livraisons, le coût de la construction pour l'assemblage, l'intégration, d'homologation, de pré-production de plates-formes peut être élevé.
  Une solution est de construire, à la fois, les stocker dans une des livraisons section de votre SVN, et de les utiliser directement dans votre environnement différent.
  Note:
  Cela s'applique également aux éléments de développement: si vous avez une Jaxb processus qui génère 900 POJO fichiers (via XML binding), et vous avez besoin de télécharger le développement dans de multiples environnements, vous pouvez 1 comprimé de copie de fichier de transaction, plutôt que de 900 ceux.

Donc, oui, il est "acceptable/bon magasin d'exécution des binaires dans le SVN"... pour les bonnes raisons.

Answer 2

Non, ne pas stocker les fichiers binaires à côté de leur code source (sauf si vous avez de bonnes raisons que compenser les inconvénients).

Inconvénients:

• il encourage les mauvais construire des pratiques dans les grands projets. La meilleure pratique est d'automatiser entièrement le processus de construction. Commettre binaires vous permet d'ignorer que: "tout faire manuellement la construire pour les parties qui ont changé" :-(
• ralentissement des mises à jour et s'engage
• s'engage qui modifier le code source, mais pas le correspondant binaires causer de la confusion parmi les développeurs. Comment détecter qu'il y a un décalage?
• svn update permettra de mettre à jour l'horodatage de vos fichiers binaires, déroutant vos outils de construction qui sera l'erreur de croire que les binaires sont plus récents que votre code source modifications.
• il utilise plus d'espace disque dans le référentiel. (Cela peut être négligeable en fonction de votre projet.)

En général, éviter de commettre tout ce qui est générée automatiquement de façon déterministe à partir d'autres versionnées ressources. Pas de redondance -> pas de possibilité pour les incohérences.

Au lieu de cela, utiliser un serveur d'intégration continue pour reconstruire automatiquement (et exécuter les tests) sur chaque commit. Laisser ce serveur de génération de publier les fichiers binaires quelque part (en dehors de SVN) si nécessaire.

Maintenant, cela ne signifie pas que vous devriez prendre cela comme une règle absolue, ou d'éviter tous les fichiers binaires. Par tous les moyens, de mettre vos outils de construction et de tiers closed-source binaires à l'intérieur de vos projets. Et de faire des exceptions lorsque cela a du sens. Idéalement, un nouveau développeur doit être capable de faire un check-out et immédiatement lancer le script de build sans dépenser un ou deux jours sur la mise en place de son environnement.

Answer 3

Je dirais que si cela simplifie la vie de votre équipe, faites-le. Si cela réduit le temps nécessaire pour mettre en place un environnement de développement fonctionnel, foncez.

Answer 4

Comme beaucoup l'ont déjà dit, c'est acceptable.

Oui, il est pratique d'avoir tout à portée de main à partir d'un emplacement, d'où vous pouvez (par exemple) la caisse d'une ancienne balise déjà sous forme binaire, avec ses dépendances correct.

Mais c'est PAS bon, surtout pour des fins de sauvegarde. Nous stockons tous nos fichiers binaires (et une partie des dépendances) dans le SVN et que le projet a augmenté, de sorte que le binaire section ne.

Malheureusement, svnadmin dump seulement des dumps tout, vous ne pouvez pas spécifier un chemin d'accès au référentiel à exclure. Ainsi, les sauvegardes et les mises à niveau du serveur svn) est devenu très douloureux!

Si vous ajoutez que, après une pas si longtemps, dans notre cas, ces binaires n'ont pas été plus utile, je suis sûr que je ne vais pas le faire à nouveau dans un cas similaire (mais je le ferais pour un projet plus petit).

Donc je vous conseille de réfléchir à deux fois avant de faire cela et d'essayer de prévoir quelle taille peut-on cultiver et quoi d'autre qui pourrait arriver.

Answer 5

Pas à cette fin, non. Vous devez utiliser un magasin de fichiers externe, comme un serveur FTP ou Web. De cette façon, il est facile de télécharger une version particulière de votre binaire d'exécution sans avoir à mettre à jour cette révision dans SVN auparavant.