¿Sistemas de control de versiones para proyectos de hardware?

¿Cuáles son algunos de los buenos sistemas de versiones para proyectos de hardware? ¿Hay equivalentes de Google Code, CVS y SVN? ¿Son adecuados estos sistemas de control de versiones para proyectos de hardware que involucran archivos PCB, esquemas ... (incluso código de firmware)?

Básicamente, todos los sistemas VCS pueden manejar archivos de texto y binarios con gracia. Por supuesto, no puedes fusionar los binarios.

Por lo tanto, siempre que no esté usando cosas obsoletas como CVS, será bueno con CUALQUIER sistema.

He usado Subversion con Altium antes. Funcionó con éxito, pero en ese momento la falta de una herramienta diff lo hacía menos útil que el control de versiones con código. Todavía creo que valió la pena hacerlo, incluso sin capacidad de diferenciación.

Para firmware, Subversion o Git son geniales. Si no ha usado Git antes, intente Subversion primero (aunque hará que aprender Git más tarde sea más difícil).

Altium ha presentado recientemente una herramienta diff para esquemas y PCB, por lo que espero que Subversion ahora sea genial, modulando la locura habitual que los vendedores de EDA logran incorporar a sus productos.

He tenido la intención de probar esto con la nueva herramienta diff; si lo hago, intentaré recordar publicar un enlace al repositorio aquí como ejemplo.

Actualizar

Probé esto, y tengo que decir que estoy un poco decepcionado con la herramienta Altium diff. Es funcional, pero los cambios entre las revoluciones de la placa son lo suficientemente importantes como para que no sea tan útil, al menos para mí. Después de ver esto, decidí olvidarme de la herramienta diff y simplemente usar Github. Aquí está el repositorio si está interesado: https://github.com/rascalmicro/pcb

Uso el cliente VisualSVN Server + TortoiseSVN, y funciona bien

Utilizo Google Code para alojar Super OSD , un proyecto electrónico mío.

Utilizo exclusivamente la suite gEDA para administrar mis esquemas y PCB. De manera útil, gEDA produce archivos de texto (que en su mayoría son legibles por humanos, aunque es difícil de interpretar) para los esquemas, en lugar de blobs binarios, como Eagle. Por ejemplo, esta es una diferencia entre dos esquemas , uno de aproximadamente 5 días y uno que acabo de presionar. No es particularmente útil ya que en realidad no puede ver muchos cambios en los archivos de texto, pero puede mostrar un cambio relativo, es decir, un trabajo masivo versus un cambio de un solo componente, y le permite volver a versiones anteriores.

El truco es usar algo que funcione bien con los binarios. Si usa mucho los archivos binarios y comparte con otros, podría ser beneficioso implementar un mecanismo de bloqueo en esos archivos binarios. Nos hemos encontrado con muchos problemas al usar Subversion con archivos binarios y compartirlos con otros que surgieron debido a la falta de semántica de bloqueo y sobreescritura / fusión de archivos binarios juntos. Agregar un mecanismo de bloqueo en esos archivos elimina el error humano en la comunicación sobre quién editó / cambió el archivo binario.

Si no ha usado el control de versiones antes, le recomiendo leer sobre las diferentes formas en que funcionan y seleccionar uno para satisfacer sus necesidades con las que usted y / o su equipo puedan sentirse cómodos. Los sistemas de control de versiones distribuidos proporcionan muchos beneficios sobre los sistemas cliente-servidor, pero tienden a ser más complicados de trabajar.

¿Por qué no usar solo Google Code o un repositorio SVN? Como este es un sistema de control de revisión. No hay un uso definido para ello. Es increíblemente útil para múltiples desarrolladores y para monitorear cambios en el código fuente.

He usado Subversion con Altium antes.

Utilizo SVN con la integración de Altium para la captura esquemática: funciona bien. Debo decir que el visor de diferencias es mejor que no tener nada, porque mis archivos SchDoc son binarios, es decir, imposible de comparar. Utilizo el cliente SVN integrado en Altium Designer en paralelo con TortoiseSVN sin ningún problema. El cliente de Altium es un poco limitado en términos de características SVN. Hago mis "etiquetas" con Tortoise.

Mi opinión se basa en Altium Designer 10, compilación 27009, y en la versión 13.1, compilación 27559.

svn, hg y git funcionan bien.

No es un sistema de control de versiones real, pero Dropbox maneja también la revisión de archivos y los pone a disposición de diferentes personas en diferentes sistemas operativos. - sistema de control de versión pobre del hombre;)

Estuve en el Maker Faire en San Mateo el pasado fin de semana y conocí a algunos representantes de una nueva (para mí) compañía llamada Up-Verter . Básicamente, están construyendo una herramienta CAD eléctrica que se ejecuta en "la nube" (es decir, en su navegador) y se construye conceptualmente en torno a la colaboración, por lo que debe tratar con merge / diff y las cosas habituales de versiones.

Todavía no lo he probado, y todavía se ve un poco verde (no creo que puedas hacer un diseño de pcb todavía, solo esquemas), pero es algo intrigante. Afirmaron que podían importar archivos Eagle, lo cual es una ventaja.

También hablé con los representantes de Eagle en la carpa Element 14, e indicaron que se están moviendo a un formato XML, lo que es un gran paso para hacer que las versiones de esquemas y diseños sean más plausibles ... todos los avances interesantes en este frente !

Altium buenas noticias!

Altium agregó soporte a la versión de control de Git como se puede ver en las Notas de la versión de Altium Designer .

Para saber cómo usarlo, puede seguir esta guía de Uso de Control de versiones .

Esta es de hecho una muy buena pregunta. Dado que los FPGA entran en la categoría de "hardware", es posible que le interese una estructura de proyecto amigable con el control de versiones que propongo para proyectos FPGA:

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

Creo que las ideas y conceptos podrían aplicarse fácilmente a otros proyectos de hardware, y en general. (Los comentarios sobre esta propuesta son bienvenidos, por cierto).

Evita git. No maneja bien los repositorios grandes. Y sus repositorios crecerán a menos que usted

1. Tener archivos esquemáticos binarios que solo cambian un poco cuando cambian
2. Active tratar binarios como texto.

He estado utilizando múltiples repositorios Mercurial (HG) (uno por proyecto) para esto, pero como la mayoría de los sistemas de control de versiones experimentarán, los repositorios son cada vez más grandes.

Deberías probar Jabalí . Está diseñado desde cero para manejar grandes archivos y repositorios. 100 GB o más de datos binarios no son un problema.

Solo me gustaría agregar un enlace a HgInit, una excelente introducción a Mercurial si decides seguir esa ruta. Personalmente uso Git, pero son muy similares en términos de arquitectura (ambos son sistemas de control de versiones distribuidos). La naturaleza distribuida de ellos los hace excelentes para trabajar en equipos bien "distribuidos". :)

http://hginit.com/

OpenPLM parece ofrecer algunos aspectos de lo que está buscando, aunque no parece estar en desarrollo activo ( http://www.openplm.org/trac/discussion/topic/93 ).

Tal vez eche un vistazo a https://discuss.erpnext.com/t/erpnext-git-github-for-open-source-hardware-call-for-beta-user-s/18006 ("ERPNext: Git / Github para Hardware de código abierto: llame para usuarios beta ")

Vale la pena pensar en esto para cualquier descripción ascii de hardware. Una vez que se adopta una descripción legible por humanos para el hardware, cualquier sistema moderno de control de revisiones (RCS) funciona bastante bien. Los diseños de circuitos generalmente están completamente descritos por los archivos de Gerber, UML describe otras partes, que son descripciones completamente ascii. Existen formatos ascii menos estándar para esquemas, diseño mecánico, etc. (KiCAD por ejemplo).

La adopción es más una cuestión práctica, requiere un requisito reconocido para un buen control de revisión, incluida una diferencia significativa. Lo que a menudo también significa renunciar a Word, Excel, PowerPoint, etc. Un argumento muy difícil en contra de los gerentes y los MBA, pero las industrias reguladas como dispositivos médicos, aviación y militares ya requieren un buen control de revisión.

Como otros han señalado, la mayoría de los RCS modernos revisarán los archivos binarios de control, lo cual es muy útil para archivar e identificar versiones, pero cualquier sistema de gestión de documentos electrónicos (EDMS), Agile, por ejemplo, puede asignar un número de revisión a un binario arbitrario. Aburrido.

Aunque no es gratis, y apenas está libre de errores, Altium Vault hace un excelente trabajo; Puedo retroceder a cualquier punto de confirmación fácilmente (tal como debería hacer cualquier VCS) muy fácilmente.

En esta área, Altium está muy por delante de las herramientas premium (Mentor y Cadencia).

Yo no trabajo para Altium pero esta herramienta, a pesar de los problemas actuales, hago hardware completo de versiones muy simple.