Flusso di lavoro del controllo del codice sorgente per la gestione di una piattaforma software

Question

Flusso di lavoro del controllo del codice sorgente per la gestione di una piattaforma software

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (-1 voti)

3

Sono responsabile di una piattaforma software, scritta in C, che viene utilizzata per fornire una varietà di progetti ai clienti. Sto cercando di migliorare il flusso di lavoro per le persone che utilizzano questa piattaforma e verificare se il controllo del codice sorgente (Mercurial è il candidato più probabile) può aiutare.

La piattaforma viene utilizzata solo internamente per ~ 10 progetti / anno. Ha una vasta gamma di funzionalità e molti bit che non sono utilizzati nella maggior parte dei progetti. Di conseguenza, ci sono molti bug nascosti.

Mi chiedo se qualcuno ha un'esperienza simile, gestendo o utilizzando una piattaforma costantemente aggiornata in questo modo.

La situazione attuale

Lo sviluppo della piattaforma avviene con un repository mercuriale, ma le versioni della piattaforma non vengono eseguite tramite mercurial. Per una versione, i file della piattaforma vengono inseriti in un archivio tar su un server centrale. Per qualsiasi sistema connesso al core, l'avvio del processo di build copia il tarball aggiornato e lo decomprime nel codice sorgente dell'applicazione. I programmatori di applicazioni non possono modificare i file core (i vari comandi sono alias tramite script di shell e ottengono un errore se provano).

Quello che sto cercando

Sembra che dovrebbe essere possibile usare in qualche modo Mercurial per gestirlo. Potremmo facilmente mantenere un ramo di rilascio della piattaforma e fare in modo che i progetti clonino il ramo di rilascio come punti di partenza.

Ma non sono sicuro di dove andrà dopo. Su un progetto, la funzionalità è completamente al cliente. Se i file core sono sbloccati, le persone inizieranno immediatamente a modificarli, anche quando c'è un modo migliore (questo è quello che è successo prima del lockdown). Ciò significherebbe che la fusione in nuove modifiche fondamentali diventa difficile e sospetto che molti gruppi non si preoccuperanno.

La draconiana soluzione di bloccare i file core e forzare gli aggiornamenti automatici a tutti i progetti è stata davvero un successo: otteniamo più reclami e problemi dai progetti che sono stati disconnessi, rispetto a quelli che ricevono gli aggiornamenti forzati. Tuttavia, non appena i progetti vengono sottoposti a test, devono essere disconnessi. Dopodiché, a parte la fusione manuale, non ricevono più aggiornamenti della piattaforma.

version-control mercurial c platforms

posta asc99c 17.01.2012 - 11:28

fonte

4 risposte

Leggi altre domande sui tag version-control mercurial c platforms

Come ottimizzare la metodologia per raccogliere i dati di mercato? Chi è l'autore / creatore del modello di deposito?

score 2 · Answer 1

Ho affrontato problemi simili con diversi sapori di approvazione commit . Inoltre, utilizza ACL (e in alcuni casi in cui è richiesta la sicurezza) CheckGpgSig .

Ho in qualche modo imbrogliato che per ogni progetto che ho impostato, costringo la gente a utilizzare uno script di configurazione (csh | sh) che, se necessario, (1) avviserà o (2) solleciterà loro ad aggiornare il loro albero.

score 1 · Answer 2

Non sono un gur Mercurial o dei sottostanti in nessuna forma, ma penso di poter usare i sottoregisti ( Aragost Kick-start e Wiki ) nel tuo lavoro.

cioè:

Avere piattaforma in (separato?) repository
Collegalo a tutti i progetti come sottoreposizione (invece di copia diretta)

In questo modo ottieni

Facile pubblicazione di versioni sui progetti (aggiornamento del sottoreportato al cset necessario, commit nel repository principale)
Il codice piattaforma è effettivamente bloccato (se gli sviluppatori di progetti non hanno i diritti per spingere nel repository di piattaforma remoto, non possono cambiare e commettere) - TBT !!!

score 1 · Answer 3

Non sono nemmeno un utente Mercurial, ma sembra che tu stia cercando qualcosa di simile a ciò che gli utenti di subversion (come me) chiamano "esterni" - la possibilità di estrarre una libreria condivisa (la tua "piattaforma / core") in diversi progetti, che possono risiedere in diversi repository. Ecco un link a un'estensione mercuriale che fornisce la stessa funzionalità

link

Cerca su google "esterni esterni" ti fornirà altri link.

L'utilizzo della funzione "esterno" ti consente di

definisce esattamente quale revisione della lib vuoi usare nel tuo progetto; anche quando vengono verificate nuove revisioni della lib, non sei obbligato a usarle immediatamente
impedisce che le modifiche alla lib vengano direttamente reimpegnate al repository dal progetto using

Ci sono, naturalmente, alcune altre cose che puoi fare, indipendentemente dal tuo specifico sistema di controllo della versione.

Se non vuoi che gli utenti della tua lib modifichino il codice sorgente, perché non fornire una versione "solo binaria" di esso? Questo è un modo molto efficace per impedire loro di modificare "il nucleo". Se questa non è un'opzione, forse potresti aggiungere una dichiarazione di non responsabilità "NON MODIFICARE" ad ogni file sorgente. In realtà, chiunque può ignorare quel commento, ma poi sarà più facile per te rifiutare l'assistenza.

D'altro canto, se in realtà vuoi che (alcuni) utenti della tua lib modifichi il codice sorgente della lib, non dovresti dare loro un tarball, ma crea un ramo speciale nel tuo repository per loro. In questo modo sarà molto più facile unire le modifiche più tardi.

Un'altra cosa: hai test automatici (unit & test di integrazione) per la tua piattaforma? Potrebbe essere molto (!) Utile per la tua situazione. Prima di unire qualcosa al tronco della tua piattaforma, puoi eseguire questi test per assicurarti che gli utenti della tua piattaforma non abbiano brutte sorprese quando si aggiornano all'ultima versione.

score -1 · Answer 4

Potresti provare git

Il progetto del kernel Linux lo sta usando, github lo sta usando, ... lo sta usando.

Per i file principali che i programmatori di applicazioni non possono modificare, puoi utilizzare:

git update-index --assume-unchanged file\*

When these flags are specified, the object names recorded for the paths are not updated. Instead, these options set and unset the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell git when you change the working tree file. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files). You should remember that an explicit git add operation will still cause the file to be refreshed from the working tree. Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.