Domanda

Usare le interfacce online per un sistema di controllo della versione è un buon modo per avere una posizione pubblicata per le versioni più recenti del codice.Ad esempio, ho un pacchetto LaTeX qui (che viene rilasciato a CTAN ogni volta che viene verificato che le modifiche funzionino effettivamente):

http://github.com/wspr/pstool/tree/master

Il pacchetto stesso è derivato da un singolo file (in questo caso, pstool.tex) che, una volta elaborato, produce la documentazione, il file readme, il file di installazione e i file effettivi che compongono il pacchetto così come viene utilizzato da LaTeX.

Per facilitare gli utenti che desiderano scaricare questo materiale, includo tutti i file derivati ​​menzionati sopra nel repository stesso, nonché il file principale pstool.tex.Ciò significa che avrò il doppio del numero di modifiche ogni volta che eseguo il commit perché il file del pacchetto pstool.sty è un sottoinsieme generato del file master.

Si tratta di una perversione del controllo della versione?


@Jon Limjap ha sollevato un buon punto:

Esiste un altro modo per pubblicare i file generati altrove per il download, invece di fare affidamento sul controllo della versione come server di download?

Questo è davvero il nocciolo della questione in questo caso.Sì, le versioni rilasciate del pacchetto possono essere ottenute altrove.Quindi ha davvero più senso eseguire la versione solo dei file non generati.

D'altra parte, @Madiril commento che:

la comodità, che è reale e ripetuta, supera i costi, che vengono sostenuti dietro le quinte

è anche piuttosto pertinente in quanto se un utente trova un bug e lo correggo immediatamente, può andare al repository e prendere il file necessario per continuare a lavorare senza dover eseguire alcun passaggio di "installazione".

E questo, penso, è il caso d'uso più importante per il mio particolare insieme di progetti.

È stato utile?

Soluzione

Sto utilizzando Tortoise SVN per lo sviluppo di piccoli sistemi ASP.NET.La maggior parte del codice viene interpretato ASPX, ma esistono circa una dozzina di DLL binarie generate da una fase di compilazione manuale.Anche se in teoria non ha molto senso avere la versione di questo codice sorgente, è certamente conveniente assicurarsi che siano correttamente rispecchiati dall'ambiente di sviluppo al sistema di produzione (un clic).Inoltre, in caso di disastro, il ripristino al passaggio precedente avviene nuovamente con un clic in SVN.

Quindi ho morso il rospo e li ho inclusi nell'archivio SVN: la comodità, che è reale e ripetuta, supera i costi, che vengono sostenuti dietro le quinte.

Altri suggerimenti

Non eseguiamo la versione dei file che possono essere generati automaticamente utilizzando gli script inclusi nel repository stesso.Il motivo è che dopo un checkout, questi file possono essere ricostruiti con un solo clic o comando.Nei nostri progetti cerchiamo sempre di renderlo il più semplice possibile, evitando così la necessità di controllare le versioni di questi file.

Posso immaginare uno scenario in cui ciò potrebbe essere utile se "taggare" versioni specifiche di un prodotto, da utilizzare in un ambiente di produzione (o qualsiasi ambiente non di sviluppo) in cui gli strumenti necessari per generare l'output potrebbero non essere disponibili.

Utilizziamo anche target nei nostri script di build in grado di creare e caricare archivi con una versione rilasciata dei nostri prodotti.Questo può essere caricato su un server di produzione o su un server HTTP per il download da parte degli utenti dei tuoi prodotti.

Non necessariamente, anche se le migliori pratiche per il controllo del codice sorgente consigliano di non includere i file generati, per ovvi motivi.

Esiste un altro modo per pubblicare i file generati altrove per il download, invece di fare affidamento sul controllo della versione come server di download?

Normalmente, i file derivati ​​non dovrebbero essere archiviati nel controllo della versione.Nel tuo caso, potresti creare una procedura di rilascio che crei un tarball che includa i file derivati.

Come dici tu, mantenere i file derivati ​​nel controllo della versione non fa altro che aumentare la quantità di rumore che devi affrontare.

In alcuni casi lo facciamo, ma è più un caso d'uso di tipo amministratore di sistema, in cui i file generati (ad esempio, file di zona DNS creati da uno script) hanno un interesse intrinseco di per sé e il controllo di revisione è una traccia di controllo più lineare di controllo del codice sorgente con ramificazioni e tag.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top