Quali sono i vantaggi dei sistemi di controllo versione che versione ogni file separatamente?

15

Negli ultimi anni ho lavorato con diversi sistemi di controllo delle versioni. Per me, una delle differenze fondamentali tra loro è stata se i loro file di versione singolarmente (ogni file ha la sua numerazione e cronologia delle versioni separate) o il repository nel suo insieme (un "commit" o versione rappresenta un'istantanea dell'intero repository) .

Alcuni sistemi di controllo della versione "per file":

CVS
ClearCase
Visual SourceSafe

Alcuni sistemi di controllo della versione "intero repository":

SVN
Idiota
mutevole

Nella mia esperienza, i sistemi di controllo della versione per file hanno solo causato problemi e richiedono molta più configurazione e manutenzione per essere utilizzati correttamente (ad esempio, "specifiche di configurazione" in ClearCase). Ho avuto molti casi in cui un collega ha cambiato un file non correlato e interrotto quella che sarebbe idealmente una linea isolata di sviluppo.

Quali sono i vantaggi di questi sistemi di controllo della versione per file? Quali problemi hanno i sistemi di controllo della versione "intero repository" che i sistemi di controllo della versione per file non hanno?

version-control

— Mike Daniels
fonte

3

Penso che principalmente sia stato storicamente così e ora ci stiamo spostando dai sistemi orientati ai file ai sistemi orientati al changeset, ma dal punto di vista di oggi è difficile capire perché le persone abbiano persino provato l'approccio per file. Ottima domanda!

— Blubb,

Ci scusiamo se questa domanda risulta polemica. È il prodotto di una recente frustrazione.

— Mike Daniels,

1

@Mike Daniels: non (almeno per me) come chiedi chiaramente i vantaggi.

— Blubb,

Questi due punti di vista sono solo convenzioni diverse. Qualsiasi argomento a favore dell'uno sull'altro solleva solo contro-argomento dai partigiani dell'altra parte. Ad esempio, se si desidera un comportamento "intero rappresentante" in Clearcase, è possibile personalizzare le specifiche di configurazione per data.

— mouviciel,

SVN ha una versione per file o è cambiata anche nell'ultima versione?

— Klaim,

12

Nella mia esperienza, non ce ne sono: VCS "tutto repository" domina rigorosamente VCS "per file".

— Rein Henrichs
fonte

3

Per file ha un vantaggio quando si creano linee di prodotti (più prodotti software) dallo stesso repository.

Alcuni ambienti di contratto con i clienti richiedono prove del fatto che il loro rilascio di codice abbia SOLO le modifiche desiderate e non altre modifiche. Questo è abbastanza semplice se i numeri di versione del file sono tutti uguali.

E questo non è un esempio casuale che ho tirato fuori dal nulla.

Questo è successo l'ultima volta che stavo spedendo aggiornamenti software all'esercito americano per un sistema di cui hanno acquistato un gran numero dal mio precedente datore di lavoro. Il valore in dollari dei contratti era misurato in miliardi frazionari di dollari (quando i dollari statunitensi valevano molto di più)

Quindi aiuta alcune volte.

Stranamente: dove lavoro ora, spediamo anche a ogni cliente un prodotto diverso .... (E non è una cosa che ho deciso, nel caso te lo stessi chiedendo.)

Ho il sospetto che sia molto più comune nello spazio di difesa / aerospaziale che nelle app web termoretraibili.

— Tim Williscroft
fonte

3

Ma una branca del repository di file completo soddisferebbe anche le stesse esigenze. Ad esempio, in bzr, i rami sono completamente indipendenti dalla linea principale fino alla fusione (o alla condivisione di un repository).

— edA-qa mort-ora-y,

1

Non riesco a pensare a una singola situazione in cui il ramo in un sistema "intero repository" non esprimerebbe meglio lo stato richiesto piuttosto che basarsi su uno stato esterno al VCS per determinare quali file utilizzare in un VCS "per file". Il mio primo lavoro dopo l'università ha usato RCS, un gruppo di script per la versione del progetto e uno script di livello superiore per la versione degli script della versione - un incubo assoluto, e sì, era anche per un progetto militare. * 8 ')

— Mark Booth,

@Mark Booth, il cliente sapeva quali file venivano modificati per le correzioni che desideravano. Quindi l'audit di configurazione fisica era per numero di controllo della versione

— Tim Williscroft,

Quello che sto dicendo è che una versione + una patch controllata richiede informazioni diverse in luoghi diversi, il VCS e i revisori. Con una diramazione nel sistema "intero repository", questi due stati sono registrati come entità separate. Ora le stesse informazioni sono duplicate tra il VCS e il sistema di controllo e dovrebbero sempre corrispondere. gitpuò persino distinguere tra autore e committer, in modo da poter mantenere un repository "verificato" in cui si conoscono sia chi ha creato la patch (l'autore) sia chi lo ha verificato (il committer). Forniscici una situazione esemplare e invertirò il mio -1.

— Mark Booth,

@Mark stand quali patch? sapevano che il loro software era questo insieme di file A 1.01 B 1.05 D 1.55 E 1.44 F 1.01 e l'SVD per la versione accettata aveva informazioni di modifica file per file, ad es. E modificato per correggere il difetto 1104, vecchia versione 1.43, nuova versione 1.44 . Il cielo ci aiuti se avessimo cambiato F dalla versione 1.01. La situazione era ancora più complicata perché c'erano dei veri bug che venivano corretti, per i quali non volevano cambiamenti. Queste persone volevano il minimo set di modifiche, per raccogliere solo alcune funzionalità selezionate da un anno di sviluppo. Selezione di correzioni post-hoc.

— Tim Williscroft,

3

Non vi è alcun vantaggio rispetto al controllo delle versioni per file.

Gli svantaggi, d'altra parte, sono abbondanti e manifesti.

— William Payne
fonte

0

Potrei dire che i sistemi di controllo della versione "per file" non presentano chiari vantaggi oltre all'implementazione del VCS. I programmatori del VCS sarebbero felici di codificare quando si trattava di un versioning "per file". Sono d'accordo al punto che, è venuto storicamente.

— Arvind Chinniah
fonte

0

Non vi è alcun vantaggio nell'approccio per file quando si hanno file correlati. Qual è il caso più comune nelle impostazioni di sviluppo.

In alcuni casi particolari - / etc o. i file nella tua home directory in Unix sono gli unici che ho regolarmente - stai gestendo (principalmente) file non correlati. E poi avere un sistema che insiste per mantenere sincronizzati i cambiamenti non correlati può essere un fastidio.

— AProgrammer
fonte