Systèmes de contrôle de version pour les projets de matériel?

Quels sont certains des bons systèmes de gestion de versions pour les projets matériels? Existe-t-il des équivalents de Google Code, CVS et SVN? Ces systèmes de contrôle de version sont-ils adaptés aux projets matériels impliquant des fichiers, des schémas, des cartes à circuits imprimés .. (même le code du microprogramme)?

Fondamentalement, tous les systèmes VCS peuvent gérer les fichiers texte et binaires avec élégance. Bien sûr, vous ne pouvez pas fusionner des binaires.

Donc, tant que vous n'utilisez pas d'éléments obsolètes comme CVS, vous serez bon avec TOUS les systèmes.

J'ai déjà utilisé Subversion avec Altium. Cela a fonctionné avec succès, mais à l’époque, l’absence d’un outil de diff le rendait moins utile que le contrôle de version ne l’est avec du code. Je pense toujours que cela en valait la peine, même sans capacité de diff.

Pour les microprogrammes, Subversion ou Git sont excellents. Si vous n'avez jamais utilisé Git auparavant, essayez d'abord Subversion (même si cela rendra plus difficile l'apprentissage de Git plus tard).

Altium a récemment introduit un outil de diff pour les schémas et les circuits imprimés. Je m'attends donc à ce que Subversion soit maintenant formidable, modulo la folie habituelle que les fournisseurs d'EDA parviennent à intégrer à leurs produits.

J'ai eu l'intention d'essayer cela avec le nouvel outil de diff; Si je le fais, je vais essayer de ne pas oublier de poster un lien vers le dépôt ici à titre d'exemple.

Mise à jour

J'ai essayé cela, et je dois dire que je suis un peu dépassé par l'outil de différenciation Altium. C'est fonctionnel, mais les changements entre les tours du conseil sont suffisamment importants pour que ce ne soit pas très utile, du moins pour moi. Ayant vu cela, j'ai décidé d'oublier l'outil diff et d'utiliser simplement Github. Voici le rapport si vous êtes intéressé: https://github.com/rascalmicro/pcb

J'utilise le client VisualSVN Server + TortoiseSVN, et cela fonctionne très bien

J'utilise Google Code pour héberger Super OSD , l'un de mes projets électroniques.

J'utilise exclusivement la suite gEDA pour gérer mes schémas et mes PCB. Utilement, gEDA produit des fichiers texte (pour la plupart lisibles par l'homme, bien qu'il soit difficile de les interpréter) pour les schémas, au lieu de blobs binaires, comme Eagle. Par exemple, il s’agit d’une différence entre deux schémas , l’un vieux de 5 jours environ et l’autre que je viens de pousser. Ce n'est pas particulièrement utile car vous ne pouvez pas voir beaucoup de changements dans les fichiers texte, mais cela peut montrer un changement relatif - c'est-à-dire une retouche importante, par rapport à un changement de composant unique - et vous permet de revenir aux versions précédentes.

L'astuce consiste à utiliser quelque chose qui fonctionne bien avec les fichiers binaires. Si vous utilisez beaucoup les fichiers binaires et que vous les partagez avec d'autres personnes, il peut être intéressant de mettre en œuvre un mécanisme de verrouillage sur ces fichiers binaires. Nous avons rencontré de nombreux problèmes liés à l'utilisation de Subversion avec des fichiers binaires et au partage avec d'autres fichiers en raison d'un manque de sémantique de verrouillage et de l'écriture / fusion simultanée de fichiers binaires. L'ajout d'un mécanisme de verrouillage sur ces fichiers supprime les erreurs humaines dans la communication sur les personnes qui ont édité / modifié le fichier binaire.

Si vous n'avez jamais utilisé le contrôle de version, je vous recommande de lire plus en détail leur mode de fonctionnement et de choisir celui qui répond le mieux à vos besoins et à celui de votre équipe. Les systèmes de contrôle de version distribués offrent de nombreux avantages par rapport aux systèmes client-serveur, mais ont tendance à être plus compliqués à utiliser.

Pourquoi ne pas utiliser simplement Google Code ou un dépôt SVN? Comme il s’agit d’un système de contrôle de révision. Il n'y a pas d'utilisation définie pour cela. Il est simplement incroyablement utile pour plusieurs développeurs et pour surveiller les modifications du code source.

J'ai déjà utilisé Subversion avec Altium.

J'utilise SVN avec l'intégration Altium pour la capture schématique: cela fonctionne bien. Je dois dire que le visionneur de diff est préférable à ne rien avoir, car mes fichiers SchDoc sont binaires, c'est-à-dire impossible de comparer autrement! J'utilise le client SVN intégré à Altium Designer en parallèle de TortoiseSVN sans aucun problème. Le client d'Altium est un peu limité en termes de fonctionnalités SVN. Je fais mes "tags" avec Tortoise.

Mon avis est basé sur Altium Designer 10 build 27009 et la version 13.1 build 27559.

svn, hg et git fonctionnent parfaitement.

Pas un vrai système de contrôle de version, mais Dropbox gère également la révision des fichiers et les rend disponibles pour différentes personnes sur différents systèmes d'exploitation. - système de contrôle de version de l’homme pauvre;)

J'étais au Maker Faire à San Mateo le week-end dernier et j'ai rencontré des représentants d'une nouvelle société (pour moi) appelée Up-Verter . Ils construisent essentiellement un outil de CAO électrique qui s'exécute dans "le nuage" (c'est-à-dire dans votre navigateur) et qui repose sur une conception conceptuelle basée sur la collaboration.

Je ne l'ai pas encore essayée, et ça a toujours l'air un peu vert (je ne pense pas que vous puissiez réellement faire la mise en page de circuits imprimés, juste des schémas), mais c'est un peu intriguant. Ils ont affirmé qu'ils pourraient importer des fichiers Eagle, ce qui est un avantage.

J'ai également parlé aux représentants Eagle de la tente Element 14, qui ont indiqué qu'ils passaient au format XML, ce qui représente un grand pas en avant pour rendre la version des schémas et de la mise en page plus plausibles ... toutes les avancées intéressantes à cet égard. !

Altium bonne nouvelle!

Altium a ajouté la prise en charge de la version de contrôle Git, comme vous pouvez le constater dans les notes de publication pour Altium Designer .

Pour savoir comment utiliser, suivez ce guide d’ utilisation du contrôle de version .

C'est en effet une très bonne question. Étant donné que les FPGA entrent dans la catégorie du "matériel", une structure de projet adaptée au contrôle de version que je propose pour les projets FPGA pourrait vous intéresser:

http://www.saardrimer.com/fpgaproj/

Je pense que les idées et les concepts pourraient facilement s’appliquer à d’autres projets matériels, et en général. (Les commentaires sur cette proposition sont les bienvenus, au fait.)

Évite les git. Il ne gère pas bien les grands référentiels. Et vos dépôts deviendront grands à moins que vous

1. Avoir des fichiers schématiques binaires qui changent un peu quand ils changent
2. Activer traiter les fichiers binaires en tant que texte.

J'ai utilisé plusieurs dépôts Mercurial (HG) (un par projet) pour cela, mais comme la plupart des systèmes de contrôle de version le constateront, les dépôts deviennent de plus en plus grands.

Tu devrais essayer Boar . Il a été conçu pour gérer des fichiers et des référentiels énormes. 100 Go ou plus de données binaires ne posent aucun problème.

J'aimerais simplement ajouter un lien vers HgInit, une excellente introduction à Mercurial si vous décidez de suivre cette voie. Personnellement, j'utilise Git, mais leur architecture est très similaire (les deux sont des systèmes de contrôle de version distribués). Leur nature distribuée les rend parfaits pour bien travailler dans des équipes "distribuées". :)

http://hginit.com/

OpenPLM semble offrir certains aspects de ce que vous recherchez bien qu’il ne semble pas être en développement actif ( http://www.openplm.org/trac/discussion/topic/93 ).

Jetez un coup d’œil à https://discuss.erpnext.com/t/erpnext-git-github-for-open-source-hardware-call-for-beta-user-s/18006 ("ERPNext: Git / Github pour Matériel Open Source - Appel à un utilisateur bêta ")

Cela vaut la peine d’être pris en compte pour toute description matérielle ascii. Une fois qu'une description lisible par un humain du matériel est adoptée, tout système de contrôle de révision (RCS) moderne fonctionne plutôt bien. Les fichiers Gerber décrivent en détail les schémas de circuits, UML décrit d’autres parties, qui sont des descriptions entièrement ascii. Il existe moins de formats ascii standard pour les schémas, la présentation mécanique, etc. (KiCAD par exemple).

L’adoption est plus une question pratique, elle nécessite une exigence reconnue pour un bon contrôle de la révision, y compris une différence significative. Ce qui signifie également souvent renoncer à Word, Excel, PowerPoint, etc. Un argument très difficile contre les gestionnaires et les MBA, mais des industries réglementées telles que les dispositifs médicaux, l'aviation et l'armée nécessitent déjà un bon contrôle de la révision.

Comme d'autres l'ont souligné, la plupart des RCS modernes contrôlent les fichiers binaires de contrôle de révision, ce qui est très utile pour l'archivage et l'identification des versions - mais tout système de gestion de documents électroniques (EDMS), Agile par exemple, peut affecter un numéro de révision à un fichier binaire arbitraire. Ennuyeuse.

Même s’il n’est pas gratuit et qu’il n’est pas exempt de bogues, Altium vault fait un travail remarquable. Je peux facilement revenir à n'importe quel point de validation (comme tout VCS devrait le faire).

Dans ce domaine, Altium est bien en avance sur les outils premium (Mentor et Cadence).

Je ne travaille pas pour Altium mais cet outil, malgré les problèmes actuels, simplifie énormément la gestion des versions de matériel.