In che modo i sistemi di controllo delle versioni distribuiti gestiscono la frammentazione?

Question

In che modo i sistemi di controllo delle versioni distribuiti gestiscono la frammentazione?

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

6

Ecco lo scenario:

X è l'autore di un software. X rilascia v1.0 su una licenza open source su Github e si sposta su. Le persone interessate al fork del software e migliorare il software. Ora ci sono 15 differenti versioni del software. Pochi cercano anche di inviare una richiesta di pull, tuttavia poiché X non funziona più sul software, la richiesta pull è semplicemente inattiva sulla sua pagina del progetto.

Come nuovo utente che desidera utilizzare la versione più attiva e stabile del software, come apprende quale dei 15 dovrebbe clonare e utilizzare? Certamente vorrebbe usare il ramo più attivo, dal momento che potrebbe avere più correzioni di bug e aggiornamenti di funzionalità.

Vedo che il modello funziona per progetti open-source più grandi, perché l'autore del software è solitamente ben noto nella comunità. Di conseguenza, la base utenti sa inavvertitamente da quale ramo clonare. Tuttavia, come si risolve un problema per un software, in cui l'autore, il manutentore e diversi contributori sono praticamente sconosciuti nella comunità open source?

git open-source mercurial

posta Vaibhav Bajpai 22.04.2013 - 20:35

fonte

3 risposte

Leggi altre domande sui tag git open-source mercurial

Esiste una teoria ben fondata sulla compatibilità a ritroso e avanzato di formati, lingue, grammatiche e vocabolari? Cambio di squadra da TFS Source Control a TFS con Git, non so come gestire la complessa struttura di progetto

score 2 · Answer 1

Questo è un problema serio e non completamente risolto. Devi solo guardare lo stato di RubyGems per vedere quanto può essere pessimo (con gemme multiple che hanno lo stesso nome, schemi di controllo delle versioni divergenti e API incompatibili).

Alla fine della giornata, se vuoi avere una community build e mantenere un pezzo di software di alta qualità, penso che sia quasi sempre necessario avere un unico repository "benedetto" con manutentori che rilasciano .

Lo sviluppo distribuito è ancora fondamentale perché consente alle persone di sperimentare sulla propria copia e in seguito di unire nuovamente le modifiche alla linea principale più lenta e più stabile.

score 2 · Answer 2

A rischio di sembrare tautologici, se si desidera un ramo attivo con correzioni di bug e aggiornamenti di funzionalità, scegliere il ramo con l'attività più recente, correzioni di bug e aggiornamenti di funzionalità. La cronologia delle revisioni è disponibile per te. Potrebbe richiedere molto tempo controllarlo per 15 rami, ma non è irragionevole.

Una volta determinato chi è il manutentore più attivo, puoi vedere se è disposto a renderlo ufficiale e parlare con gli altri per vedere se sono d'accordo. Se non stanno facendo cambiamenti selvaggiamente divergenti, non dovrebbe essere difficile trovare un terreno comune.

score 0 · Answer 3

Come notato, questo rimane un problema.

Considero quanto segue per determinare la redditività:

Attività recente sul progetto.
Quantità di attività sul progetto.
Se esiste un proprietario identificabile del progetto.
Chi altri / quali altri progetti stanno utilizzando il progetto.
Cronologia delle versioni del progetto.

Determinare l'idoneità di una forcella / applicazione non è banale, indipendentemente dal tipo di software. In genere guarderei:

Di altre persone che lo usano per risolvere gli stessi / simili problemi che hai.

Oppure puoi chiedere su stackexchange / stackoverflow. :)