Quali sono le migliori pratiche per l'eliminazione dal controllo del codice sorgente? [chiuso]

1

Quando è possibile cancellare?

... distruggere?

Quando non dovresti mai cancellare / distruggere, non importa quanti anni (ad esempio il software di gestione della salute?)

    
posta emragins 07.09.2012 - 04:14
fonte

2 risposte

5

Che cosa intendi con "cancella"? Se si desidera solo rimuovere i file dall'attuale HEAD (quale è la versione più recente chiamata nella maggior parte dei sistemi di controllo sorgente), procedere. La maggior parte dei sistemi di controllo del codice sorgente sono progettati per gestire l'eliminazione dei file.

In effetti, una volta nella storia, alcuni sistemi di controllo del codice sorgente rendono molto difficile rimuovere effettivamente le cose dalla loro storia. Se hai aggiunto un file che vuoi rimuovere, di solito è più semplice cancellare il file e fare un commit con il file rimosso.

Questa è generalmente una buona cosa. Non sai mai quando potresti voler accedere al vecchio codice. I requisiti di spazio di solito non sono significativi a meno che non si disponga di un numero enorme di grandi commit. Come dice @nonnb, potresti averne bisogno anche per scopi di controllo e conformità (ad es. ISO27001).

L'unico caso in cui qualcosa dovrebbe essere rimosso dalla cronologia delle revisioni è quando qualcosa di sensibile è stato commesso accidentalmente, come una chiave privata, password, dati di test che contengono informazioni reali sui clienti o dati potenzialmente in violazione delle norme sulla privacy (PII).

    
risposta data 07.09.2012 - 07:12
fonte
6

Per essere chiari, suppongo che per "distrutto" intenda la cancellazione permanente di tutte le versioni del file, rispetto alla semplice rimozione di un file dal ramo corrente.

IMO, la sorgente valida non dovrebbe mai essere distrutta. L'unica volta che qualcosa deve essere cancellato da un repository (almeno, in qualsiasi situazione etica) è se il file non dovrebbe essere stato lì in primo luogo, ad es. accidentalmente aggiungendo artefatti compilati come obj, bin, pch ecc nel repository.

La logica è:

  • Audit - scoprire chi ha cambiato cosa, quando e perché può essere fondamentale per arrivare a fondo di un problema e determinare l'impatto di un bug su una base di clienti anche dopo anni (e la "prova" può essere un salva lavoro quando si tratta del gioco della colpa, sfortunatamente)
  • Asset - ricorda che la fonte è una risorsa aziendale, che potrebbe dover essere trasferita se la tua azienda è venduta, unita, ecc. Distruggere vecchie versioni della fonte potrebbe essere vista in una penombra dai contatori di bean, che non saranno in una posizione per comprendere il tuo argomento secondo cui il codice non è pertinente.
  • Dimensione - I file in un VCS sono solitamente compressi , quindi non c'è molto incentivo da cancellare per liberare spazio ecc.

Una soluzione tipica per rimuovere il codice sorgente da un progetto che non è più ricercato è spostarlo o archiviarlo, sebbene ciò sia in gran parte inutile nei sistemi di controllo dei sorgenti contemporanei. (ad esempio, CVS ha un attico)

    
risposta data 07.09.2012 - 07:26
fonte

Leggi altre domande sui tag