Sistemi di controllo versione per progetti hardware?

Quali sono alcuni dei buoni sistemi di versioning per progetti hardware? Esistono equivalenti di codice Google, CVS e SVN? Tali sistemi di controllo della versione sono adatti a progetti hardware che coinvolgono file PCB, schemi ... (anche codice firmware)?

Fondamentalmente, tutti i sistemi VCS possono gestire file di testo e binari con garbo. Ovviamente non puoi unire quelli binari.

Quindi finché non stai usando cose obsolete come CVS sarai bravo con QUALSIASI sistema.

Ho usato Subversion con Altium prima. Funzionava correttamente, ma al momento la mancanza di uno strumento diff lo rendeva meno utile del controllo della versione rispetto al codice. Penso ancora che valesse la pena farlo, anche senza capacità di diff.

Per firmware, Subversion o Git sono entrambi fantastici. Se non hai mai usato Git prima, prova prima Subversion (anche se renderà più difficile l'apprendimento di Git in seguito).

Altium ha recentemente introdotto uno strumento diff per schemi e PCB, quindi mi aspetto che Subversion ora sia eccezionale, modulo la solita follia che i venditori di EDA riescono a integrare nei loro prodotti.

Volevo provare questo con il nuovo strumento diff; se lo faccio, proverò a ricordare di pubblicare un link al repository qui come esempio.

Aggiornare

Ho provato questo, e devo dire che sono un po 'deluso dallo strumento diff Altium. È funzionale, ma i cambiamenti tra i giri della scheda sono abbastanza sostanziali da non essere così utili, almeno per me. Visto questo, ho deciso di dimenticare lo strumento diff e di usare Github. Ecco il repository se sei interessato: https://github.com/rascalmicro/pcb

Uso VisualSVN Server + client TortoiseSVN e funziona perfettamente

Uso Google Code per ospitare Super OSD , un mio progetto di elettronica.

Uso esclusivamente la suite gEDA per gestire i miei schemi e PCB. Utilmente, gEDA produce file di testo (che sono per lo più leggibili dall'uomo, anche se è difficile interpretarli) per gli schemi, invece di BLOB binari, come Eagle. Ad esempio, questa è una differenza tra due schemi , uno di circa 5 giorni e uno che ho appena spinto. Non è particolarmente utile poiché in realtà non è possibile vedere molte modifiche nei file di testo, ma può mostrare cambiamenti relativi, ad esempio rilavorazioni di massa, rispetto a modifiche di singoli componenti e consente di tornare alle versioni precedenti.

Il trucco è usare qualcosa che funzioni bene con i binari. Se usi molto i binari e li condividi con altri, potrebbe essere utile implementare un meccanismo di blocco su quei file binari. Abbiamo riscontrato molti problemi con l'utilizzo di Subversion con i file binari e la condivisione con altri sorti a causa della mancanza di blocco della semantica e della sovrascrittura / fusione dei file binari insieme. L'aggiunta di un meccanismo di blocco su questi file rimuove l'errore umano nella comunicazione su chi ha modificato / modificato il file binario.

Se non hai mai usato il controllo della versione prima, ti consiglio di leggere i diversi modi in cui funzionano e selezionarne uno per soddisfare le tue esigenze con cui tu e / o il tuo team potete essere a vostro agio. I sistemi di controllo di versione distribuito offrono molti vantaggi rispetto ai sistemi client-server, ma tendono ad essere più complicati con cui lavorare.

Perché non usare semplicemente Google Code o un repository SVN? Poiché si tratta di un sistema di controllo di revisione. Non vi è alcun uso definito per questo. È incredibilmente utile per più sviluppatori e per monitorare le modifiche nel codice sorgente.

Ho usato Subversion con Altium prima.

Uso SVN con l'integrazione Altium per l'acquisizione schematica: funziona bene. Devo dire che il visualizzatore di differenze è meglio che non avere nulla, perché i miei file SchDoc sono binari, cioè impossibile confrontare diversamente! Uso il client SVN integrato in Altium Designer in parallelo con TortoiseSVN senza problemi. Il client Altium è un po 'limitato in termini di funzionalità SVN. Faccio i miei "tag" con Tortoise.

La mia opinione si basa su Altium Designer 10 build 27009 e versione 13.1 build 27559.

svn, hg e git funzionano tutti bene.

Non è un sistema di controllo della versione reale, ma Dropbox gestisce anche la revisione dei file e li rende disponibili per persone diverse su sistemi operativi diversi. - sistema di controllo versione mans scarsa;)

Sono stato alla Maker Faire di San Mateo lo scorso fine settimana e ho incontrato alcuni rappresentanti di una nuova società (per me) chiamata Up-Verter . Fondamentalmente stanno costruendo uno strumento CAD elettrico che gira nel "cloud" (cioè nel tuo browser) ed è concettualmente costruito attorno alla collaborazione, quindi dovrebbe occuparsi di merge / diff e delle solite cose di versioning.

Non l'ho ancora provato, e sembra ancora un po 'verde (non credo di poter ancora effettivamente fare il layout del pcb, solo schemi), ma è un po' intrigante. Hanno affermato di poter importare file Eagle, il che è un vantaggio.

Ho anche parlato con le rappresentanti Eagle nella tenda Element 14, e hanno indicato che si stanno spostando in un formato XML, il che è una specie di grande passo verso rendere più plausibile il controllo delle versioni di schemi e layout ... tutti gli avanzamenti interessanti su questo fronte !

Altium buone notizie!

Altium ha aggiunto il supporto alla versione di controllo Git come puoi vedere nelle Note di rilascio di Altium Designer .

Per sapere come utilizzare è possibile seguire questa guida Uso del controllo versione .

Questa è davvero un'ottima domanda. Poiché gli FPGA rientrano nella categoria di "hardware", potresti essere interessato a una struttura di progetto intuitiva per il controllo della versione che propongo per progetti FPGA:

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

Penso che le idee e i concetti possano essere facilmente applicati ad altri progetti hardware e in generale. (I commenti su questa proposta sono molto graditi, tra l'altro.)

Evita git. Non gestisce bene i repository di grandi dimensioni. E i tuoi repository diventeranno grandi a meno che tu

1. Hanno file schematici binari che cambiano in qualche modo solo quando cambiano
2. Attiva tratta i file binari come testo.

Ho usato più repository Mercurial (HG) (uno per progetto) per questo, ma come sperimenterà la maggior parte dei sistemi di controllo versione, i repository stanno diventando sempre più grandi.

Dovresti provare Cinghiale . È stato progettato per gestire file e repository di grandi dimensioni. 100 GB o più di dati binari non sono un problema.

Vorrei solo aggiungere un link a HgInit, un'eccellente introduzione a Mercurial se decidi di seguire questa strada. Personalmente uso Git, ma sono molto simili in termini di architettura (entrambi sono sistemi di controllo della versione distribuiti). La loro natura distribuita li rende ideali per lavorare bene in team "distribuiti". :)

http://hginit.com/

OpenPLM sembra offrire alcuni aspetti di ciò che stai cercando, anche se non sembra essere in fase di sviluppo attivo ( http://www.openplm.org/trac/discussion/topic/93 ).

Forse dai un'occhiata a https://discuss.erpnext.com/t/erpnext-git-github-for-open-source-hardware-call-for-beta-user-s/18006 ("ERPNext: Git / Github per Hardware open source - Chiama per utenti beta ")

Vale la pena pensare a tutte le descrizioni ascii dell'hardware. Una volta adottata una descrizione leggibile dall'uomo per l'hardware, qualsiasi moderno sistema di controllo di revisione (RCS) funziona abbastanza bene. I layout dei circuiti sono in genere completamente descritti dai file Gerber, UML descrive altre parti, che sono descrizioni completamente ascii. Esistono formati ASCII meno standard per schemi, layout meccanico e così via (KiCAD ad esempio).

L'adozione è più una questione pratica, richiede un requisito riconosciuto per un buon controllo di revisione, tra cui una differenza significativa. Il che spesso significa anche rinunciare a Word, Excel, PowerPoint, ecc. Un argomento molto difficile contro manager e MBA, ma probabilmente settori regolamentati come i dispositivi medici, l'aviazione e le forze armate richiedono già un buon controllo di revisione.

Come altri hanno sottolineato, la maggior parte dei RCS moderni controllerà i file binari di revisione, il che è molto utile per l'archiviazione e l'identificazione delle versioni, ma qualsiasi sistema di gestione elettronica dei documenti (EDMS), ad esempio Agile, può assegnare un numero di revisione a un binario arbitrario. Noioso.

Sebbene non sia gratuito e difficilmente esente da bug, Altium vault fa un ottimo lavoro; Posso tornare facilmente a qualsiasi punto di commit (proprio come dovrebbe fare qualsiasi VCS) molto facilmente.

In quest'area, Altium è molto più avanti degli strumenti premium (Mentor e Cadence).

Io non lavoro per Altium ma questo strumento, nonostante i problemi attuali, rendono l'hardware completo delle versioni molto semplice.