Qual è il modo migliore per iniziare a utilizzare il controllo versione in un progetto opensource?


10

Mi è stato suggerito di prendere il mio progetto open source a causa delle sue dimensioni e della mia mancanza di competenze, quindi ho controllato Google Code e ho iniziato a fare un progetto e ora mi sta chiedendo se voglio che il progetto abbia Git, Mercurial o Subversion hosting di codice.

Non so nemmeno cosa sia l'hosting di codice e una ricerca mi ha confuso di più con i dibattiti tra tutte queste cose, e questo è ancora peggio quando Google Code mi chiede quale tipo di licenza desidero.

Penso di non capire bene cosa significhi realmente l'open source, qualcuno può praticamente truffare un rapido profano su ciò che è tutto? Molto apprezzato.

Modifica Ci sono state molte risposte fantastiche su queste tre versioni dell'hosting di codice, ma penso che non sia riuscito a comunicare la vera domanda: in pratica non ho idea di come funzioni questa roba open source, perché dovrei ospitare il codice da qualche parte come questo ? E ciò significherebbe che devo rimuovere il sito dal mio attuale hosting o è un tipo di hosting completamente diverso? Cosa succede quando rendo il mio sito open source, quali diritti ho, quali diritti concedo. Come funziona, la gente viene e mi lancia il codice gratis? Forse queste sono domande stupide, e se è così allora suppongo di aver bisogno di risposte stupide, sul serio non ho idea di cosa sia open source, tranne il concetto di condivisione del codice ...



è stata una fantastica proiezione di diapositive, penso che mi abbia aiutato a cogliere le basi grazie per la condivisione, ora è la roba più dettagliata che mi ha reso all'oscuro.

1
Si tratta in realtà di 2 domande, ed entrambe sono probabilmente duplicati. stackoverflow.com/questions/2303136/... e stackoverflow.com/questions/3859/...
sylvanaar

2
La "mancanza di abilità" suona come una terribile ragione per rendere qualcosa di open source. Se hai un'idea magnifica, ma non hai competenze tecniche, allora forse. Non andrei all'open source fino a quando non avrò trovato un partner tecnicamente competente che è pronto a impegnarsi a produrre un primo taglio del codice e che vorrebbe andare all'open source.
Tripleee

Triplo saresti in grado di suggerire una rete o qualcosa del genere in cui potrei trovare qualcuno con cui collaborare?
Nathan,

Risposte:


7

perché dovrei ospitare il codice da qualche parte in questo modo?

Un punto chiave dello sviluppo di software open source è la condivisione del codice sorgente. Esistono diversi modi per farlo, come mettere file tar / zip su un server web o ftp. Servizi come il codice google (o sourceforge.net, gitorious.org, bitbucket.org e molti altri) eliminano la necessità di eseguire i propri server per questo scopo.

E ciò significherebbe che devo rimuovere il sito dal mio attuale hosting o è un tipo di hosting completamente diverso?

Questi servizi non sono host web generici, ma offrono servizi molto specializzati. Non sono pensati per essere la homepage di un prodotto, ma piuttosto una dashboard per sviluppatori.

Con il codice di Google ottieni

  • una wiki
  • un bugtracker
  • normale spazio per il download dei file
  • un server di controllo versione

Ovviamente è possibile configurare questi software su un normale server Web (le funzionalità di controllo della versione potrebbero essere complicate, ma ciò dipende molto dai dettagli), ma il vantaggio principale dell'utilizzo di un hoster di sviluppo è che non è necessario preoccuparsi di questi sistemi per il tuo. Lo svantaggio principale è che non hai alcun controllo su quale software viene utilizzato sul server, devi convivere con ciò che è disponibile su quell'host. Devi anche considerare cosa succede se il servizio si interrompe (ok, Google non fallisce mai) e se puoi trasferire i dati dall'host corrente a un altro o al tuo server (pensa ai backup).

Cosa succede quando rendo il mio sito open source, quali diritti ho,

Questa è una domanda difficile, poiché dipende dalla legge del paese in cui vivi.

quali diritti concedo.

Questo dipende dalla licenza che dai al prodotto. Può andare dall'open source proprietario (pensa a PGP) in cui l'utente praticamente non può fare nulla con il codice, dall'altra parte della scala c'è il dominio pubblico, dove ognuno può fare quello che vuole.

Come funziona, la gente viene e mi lancia il codice gratis?

È molto improbabile che ciò accada, poiché il tuo prodotto ha bisogno di popolarità sufficiente per attirare altri sviluppatori.

[...] e ora mi chiede se voglio che il progetto abbia l'hosting di codice Git, Mercurial o Subversion.

Questi sono tre diversi sistemi di controllo della versione, in cui Subversion è centralizzata, mentre Git e Mercurial sono distribuiti.

Ci sono guerre di religione su quale usare, ma il punto principale è usarne una. Vedere http://martinfowler.com/bliki/VersionControlTools.html per maggiori dettagli.

Quando scegliere Subversion:

  • Hai file binari, che non possono essere facilmente uniti, e hai bisogno del flusso di lavoro lock-> modifica-> commit-> sblocco, che sovversione supporta¹
  • Devi controllare solo una parte della struttura della directory.

¹ Esiste un'estensione di blocco per mercurial, ma non ne ho esperienza e non posso dire se è utilizzabile.

Quando non hai bisogno delle funzionalità precedenti, è meglio usare Mercurial o Git. Entrambi hanno i seguenti vantaggi rispetto a Subversion:

  • veloce (e con veloce intendo davvero veloce )
  • ramificazione e fusione facili (questo è migliorato da Subversion> = 1.5, ma non è lo stesso)
  • il commit e la pubblicazione sono disaccoppiati, in modo da poter lavorare senza problemi su una funzione e pubblicare il lavoro al termine
  • tengono traccia dello stato della directory del prodotto nel suo insieme
  • si ottiene una copia completa dell'intera cronologia delle versioni quando si clona un repository remoto
  • numeri di revisione crittograficamente protetti, il che significa che anche quando qualcuno si rompe nel server, non può mettere in atto il codice senza cambiare la cronologia delle revisioni

    • ma poiché nessuno controlla queste revisioni, questa funzione non è praticamente efficace

9

L'hosting di codice è esattamente questo: un posto dove ospitare (o conservare) il tuo codice.

Git, Mercurial e Subversion sono tutti strumenti di controllo del codice sorgente utilizzati per gestire la cronologia del codice. Git e Mercurial sono sistemi distribuiti mentre Subversion è un'installazione basata su server più tradizionale.

Dai un'occhiata a Wikipedia o ad alcuni di questi e vedi quale ti piace di più. Personalmente usiamo Mercurial e funziona molto bene per noi.


6

Joel Spolsky ha scritto un ottimo tutorial su Hg (Mercurial) e credo che la sezione introduttiva riguardi Subversion, compresi i motivi per cui stai aggiornando a Mercurial. Dai una lettura, mi ha davvero aiutato a capire molto su Mercurial e DVCS in generale.

Oh, e quando sei pronto per ospitare, puoi usare Google Code, BitBucket , Github (con l'aiuto di questa eccellente estensione ) o altri.


Mercurial è un sistema eccellente, mi ha conquistato dalla sovversione dopo pochi minuti di utilizzo.
Jim In Texas,

3

Uso git, che trovo più facile da gestire grazie al controllo distribuito. Hg è buono anche per questo scopo particolare, ma non posso darti consigli su di esso, non l'ho mai usato. SVN è un sistema centralizzato e quindi meno pratico, ma potrebbe essere leggermente più semplice.

L'open source fondamentalmente significa che offri a chiunque la possibilità di usare il tuo lavoro e costruirlo. Puoi impostare i limiti di quell'uso: GPL significa che l'utente deve rendere open source il suo lavoro aggiunto, LGPL significa che non lo fa, per esempio.


2

Subversion sarebbe l'opzione più semplice perché è un VCS. Git e Mercurial sono sistemi DVCS. Sono più moderni e più potenti ma più difficili da capire. Anche l'utilizzo di un front-end come TortoiseSVN o TortoiseHG (per Mercurial aka HG) aiuta davvero.

Se il tuo software è un programma autonomo, puoi usare GPL o aprirlo con una licenza BSD. Se il tuo progetto è una libreria che qualcun altro collegherà con usa LGPL o di nuovo BSD; ma non usare GPL.

[modificare]

Per quanto riguarda la tua motivazione originale per l'approvvigionamento aperto del software: Sfortunatamente, rendere il software open source non significa che otterrai un afflusso di lavoro gratuito di talento. Esistono centinaia di migliaia di progetti open source. Solo una piccola percentuale ha membri attivi. Le ragioni per cui questi progetti hanno successo o no sono varie quanto il motivo per cui le aziende hanno successo e falliscono. Se vuoi diventare un buon programmatore e produrre un buon software, dovrai dedicare molto tempo all'apprendimento, alla scrittura del codice e alla comunicazione con altre persone su siti come StackOverflow.


1
Perché dici che svn è il più semplice? Si prega di giustificare questa affermazione.

1
@Richard: penso che significhi che è un po 'più facile da configurare e utilizzare per un utilizzo di base, almeno concordo con tale affermazione. Non sono d'accordo con l'idea che la tua biblioteca non dovrebbe usare GPL, è davvero una posizione politica.
Kheldar,

Usa GPL per una biblioteca se vuoi imporre determinate restrizioni al suo utilizzo. Utilizzare LGPL se si desidera imporre meno restrizioni.
Keith Thompson,

0

Mi sembra che mentre molte persone qui rispondono al come , nessuno ha veramente risposto al perché nella tua domanda.

Uno dei primi progetti open source che ho sperimentato è stato il favoloso progetto Fractint , sviluppato dal gruppo Stone Soup che si è ispirato alla vecchia storia popolare della zuppa di pietra .

Per me, questo incapsula lo spirito dell'open source meglio di qualsiasi altra Stallman o persino del Manifesto GNU originale . È una testimonianza della forza di quella comunità che Fractint è ancora in fase di sviluppo 23 anni dopo l'accensione del fuoco sotto quella particolare pentola di codice .


0

Open source significa che chiunque può leggere, copiare, modificare e distribuire il tuo codice. Dovresti avere una solida comprensione delle implicazioni di questo prima di procedere. Forse dovresti leggere un libro o almeno sfogliare gli articoli di Wikipedia sull'argomento e / o http://opensource.org/ fino a quando senti di avere una comprensione del concetto.

(Il libro di O'Reilly Open Sources http://oreilly.com/openbook/opensources/book/index.html è utile ma forse non proprio quello che stai cercando.)

Quale sistema di controllo del codice sorgente utilizzare è completamente secondario. È possibile copiare / incollare il codice su una pagina Web ed essere fatto. Detto questo, il controllo della versione è importante e un buon veicolo per abbassare la barra per gli sviluppatori di contribuire. Qualsiasi opzione offerta da Google Code va bene; vai con quello che ti piace, o forse rinvia la domanda fino a quando non puoi chiedere ai tuoi collaboratori quale vorranno usare.


0

Rendere il tuo codice o progetto open source significa che tutti possono prenderlo e modificarlo come vuole. Questo dipende dal tipo di licenza che scegli di utilizzare, ma in generale open source significa che il codice sorgente è disponibile a chiunque per scaricarlo, modificarlo e utilizzarlo come preferisce.

Comunque questo codice deve essere raggiungibile da altre persone per ottenerlo.

Portare il codice in un repository online pubblico come GitHub è il modo migliore per farlo. Innanzitutto, il tuo codice è ora accessibile al pubblico. Quindi, poiché tali servizi offrono anche il controllo della versione, il codice è organizzato in base al progetto. Puoi tenere traccia dei cambiamenti che tu e altre persone fate. Poiché consente anche di ramificare (separare) il progetto in altri progetti diversi, è possibile tenere traccia di tutte le diverse versioni create da altri utenti del proprio codice.

Ciò garantisce anche che il codice sia archiviato in un luogo sicuro, ad esempio non devi preoccuparti che venga perso da un disco rigido difettoso sul tuo PC. E quando vuoi lavorarci, puoi lavorare da qualsiasi luogo perché il tuo codice è online, puoi trovarlo ovunque.

Se poi decidi che è il momento di mostrare il tuo codice al mondo, è solo una questione di inviare il link al tuo repository di progetti online. È una tecnologia a cui le persone si stanno abituando, quindi poiché tutti lo sanno, è più facile capire come scaricarlo, pubblicare messaggi, creare versioni diverse, ecc.

È come uno standard comune nel fare le cose, pratica comune.

Alcuni link che potresti trovare utili per spiegare ulteriormente l'open source:


-6

A proposito del sistema di controllo della versione, direi che dovresti seguire l'alternativa più usata e più recente: ovvero: "Git". Mercurial è meno popolare e SVN è vecchia, lenta e centralizzata. Con GIT potrai beneficiare di un sistema di controllo versione moderno e popolare. Non c'è praticamente nulla da perdere.

Fonti (popolarità reggarding di DVCS):

/programming/tagged/git ~ 10k domande /programming/tagged/mercurial ~ 3k domande

http://www.googlefight.com/index.php?lang=en_GB&word1=git&word2=mercurial

11700000 risultati vs

1580000 risultati

Per quanto riguarda la licenza: forse dovresti guardare quelli più comuni: GLP, MIT, LGPL, BSD e scegliere quello più adatto al tuo progetto.


7
Mercurial non è proprietario ... è open source esattamente come Git!
Christian Specht,

4
Fanboy risponde con argomenti parzialmente sbagliati.
Oben Sonne,

1
"più utilizzato": fornire un riferimento alla fonte di tali informazioni.
sylvanaar,

Scusate la gente ... È solo la mia percezione delle cose: immagino che Git sia più usato di Mercurial e so che SVN è vecchio, lento e centralizzato ... Mi chiedo se i vostri commenti siano meno commenti da fan di quelli che mi chiamano fanboy-risposta. Dai, l'hub git usa git, il kernel linux usa git, ogni progetto nel mio dipartimento usa git ...
Pedro Rolo

2
Forse l'abbondanza di domande su Git dimostra anche che è più difficile da usare? Alcune persone hanno usato dati simili quando hanno indagato quali framework di sviluppo web fossero i più "popolari" in cui è stato sollevato lo stesso punto (commentando le imprecisioni).
Tim Post
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.