Possiamo configurare il server svn su un computer locale senza accesso alla rete?

Il modo più semplice per configurare un server locale è utilizzare svnserve :

Subversion includes Svnserve - a lightweight stand-alone server which uses a custom protocol over an ordinary TCP/IP connection. It is ideal for smaller installations, or where a full blown Apache server cannot be used.

In realtà non è necessario un server di subversion, se tutto ciò che si vuole fare è accedere localmente al repository, dato che è possibile accedere a un repository di subversion tramite un URL di file, come descritto in questa risposta :

You can access the repository using file:// protocol so you will only need Tortoise SVN installed and nothing else. See this question in FAQ: Is it possible to use TortoiseSVN without a server?

You can even have the repository in the usb device so that you can take the source with you and work on in from other computers.

Se stai usando TortoiseSVN , puoi trovare le istruzioni su Creazione del repository con TortoiseSVN :

1. Open the windows explorer

2. Create a new folder and name it e.g. SVNRepository

3. Right click on the newly created folder and select TortoiseSVN → Create Repository here....

Subito sopra in questa pagina descrive anche come creare un repository da la riga di comando .

Detto questo, ti consiglio di dare un'occhiata a Mercurial o Git come alternativa a svn però. Se conosci TortoiseSvn, troverai TortoiseHg e TortoiseGit una transizione facile, in più ti dà la flessibilità di lavorare in un modo distribuito più tardi, se necessario. Ad esempio, in passato ho usato memory stick per trasferire hg repository tra macchine senza accesso alla rete, e quando si lavora in questo modo si ottiene un backup gratuito nell'affare.

Il server più semplice (e più veloce), che puoi utilizzare per lavorare con il repository locale, incorporato in ogni svn-client . Questo è il server per accedere a qualsiasi repository e qualsiasi quantità di repository , esistente sul filesystem locale, usando il file di protocollo: ///. Non fornisce alcun metodo di autorizzazione o autenticazione, garantisce solo il pieno accesso illimitato al repository sotto controllo, ma, dall'altra parte, consente di utilizzare e fornisce tutte le funzionalità del sistema VCS in sé.

Per utilizzare questo server, hai in qualsiasi directory vuota in qualsiasi posizione chiamata CLI-comando svnadmin con il sottocomando e i parametri corrispondenti (non riesco a ricordare, ci sono programmi di amministrazione nel bundle CLI-client o no e non posso controllarlo - non ho installato CLI svn-client, solo TortoiseSVN, che hanno questi programmi nell'installer nella versione 1.7) - spero, sarete in grado di trovarlo.

svnadmin help ci mostra tutti i sottocomandi disponibili, ora siamo interessati al sottocomando create .

svnadmin help create fornisce tutti i dettagli necessari per noi

create: usage: svnadmin create REPOS_PATH

Create a new, empty repository at REPOS_PATH.

Valid options:
...

Al punto di partenza per il primo deposito possiamo ignorare tutte le opzioni di regolazione fine e ricordare solo la forma principale svnadmin create REPOS_PATH , lì REPOS_PATH è il percorso assoluto o relativo alla directory vuota, pianificato per il pronti contro termine. Poiché la maggior parte del tempo di persone ordinarie di Windows per applicazioni multipiattaforma possono essere confuse, quale notazione (forward o backslash) utilizzare nel percorso (metoo), il modo più sicuro è cd in posizione, da cui è visibile la nostra dir senza percorso lungo - padre della futura directory repo o della directory stessa. Per il previsto repo z:\Main prima svnadmin create

Z:
cd \Main

e, infine,

svnadmin create .

Come risultato, abbiamo creato un repository vuoto nella directory, che è mostrato in Esplora risorse con un'icona speciale come indicatore di contenuto

Ora,ognivoltachequestorepositoryènecessario,usiamoisoliticomandiSVN,làlapartedell'URLoiparametrisembranocomefile:///Z:/Main

c:\>svnlsfile:///Z:/Mainbranches/tags/trunk/

(Hoaggiuntounalberodirepositorystandardnelrepository).

AnalizziamoquestostranoURL:

• file:///,comeperqualsiasiURL,significaaccesso-protocollo,nelnostrocasoilprotocolloèspecialeehatre,nonduebarre
• Z:/Mainèilpercorsocompletoperilrepoconl'unitàeilpercorsoall'internodeldisco,tuttiibackslashdiWindowssostituitidalle"avanzate" barre in avanti

Da qualsiasi altro punto questo repository non ha alcuna differenza da "Big Brothers" con server speciali di Subversion

Consente di provare una risposta che consiglia soluzioni generiche anziché specifiche.

In primo luogo sì, puoi utilizzare Subversion su un computer autonomo: puoi installare il server localmente oppure puoi lavorare con file: //

Ma a meno che non ci sia una buona ragione per usare la sovversione, suggerirei che questa non è la soluzione migliore per il problema del controllo della versione locale - non ultimo perché non riesce ad avere una delle cose che considero essenziali assicurandoti che il tuo codice sorgente sia in almeno due posti (sì, anche per cose personali). Suggerirei quindi l'uso di un sistema di controllo delle versioni distribuito (DVCS).

Uno dei vantaggi di DVCS è che, una volta installati gli strumenti, i repository sono autonomi all'interno di una cartella ed è possibile sincronizzare il contenuto tra diverse cartelle contenenti lo stesso "repository" purché si abbia accesso a livello di file. Hai anche la possibilità di parlare con le versioni "server" di quei repository (che sono ospitati privatamente o che sono disponibili come servizio). Ciò rende la vita molto più semplice eseguendo tutto localmente.

Ci sono anche altri vantaggi per DVCS.

Come ho già notato, non penso che tu abbia una vera soluzione VCS finché il tuo codice non è su almeno due macchine (in particolare due distinti dischi rigidi e idealmente in più di una posizione - sebbene clonazione e spinta a dire La chiavetta USB o l'archiviazione "cloud" (skydrive, dropbox e così via) è un altro modo che dovrebbe funzionare altrettanto bene.

In termini di DVCS, guarderei Mercurial (Hg) e Git e anche Veracity . Io uso Mercurial perché è ancora più bello su Windows ...

Se parli di servizi in hosting, in realtà sono d'accordo sul fatto che ci sia un sacco di cose da lodare per github - ma ci sono anche molte cose carine su bitbucket e Fogbugz / Kiln ... e lo stesso è probabilmente vero per molto di altri servizi che non ho elencato (ad es. link che è stato menzionato in precedenza su twitter oggi)

Subversion non richiede un server. Utilizza un repository centralizzato, ma è possibile accedere a questo repository attraverso il metodo di accesso "file", il che significa che è sufficiente accedere al filesystem su cui è archiviato il repository. Il modo più semplice per configurarlo è creare una cartella da qualche parte sul tuo hdd, puntare a TortoiseSVN (o uno strumento simile) e "creare repository qui". Da lì, puoi fare tutto il necessario per ottenere il tuo codice nel repository.

Tuttavia, a lungo termine, probabilmente stai meglio usando un SCM distribuito, i migliori candidati sono git (più potente, curva di apprendimento ripida, funziona meglio su * nix) e mercuriale (leggermente meno potente, facile da imparare , funziona altrettanto bene su windows e * nix). Con questi, la tua copia di lavoro contiene l'intero repository e puoi creare quanti cloni (remoti o locali) come desideri. È possibile avviare localmente e, se si decide di ospitare esternamente il repository, è sufficiente clonare il repository locale esistente nella posizione esterna e sincronizzarlo in entrambe le direzioni in qualsiasi momento. Ancora meglio, poiché ciascuno dei tuoi cloni contiene l'intera cronologia del progetto, SCM funge anche da sistema di backup. Con la sovversione, se il tuo server muore e non hai eseguito il backup, la tua cronologia non c'è più: con git, basta clonare la tua copia di lavoro su un nuovo server e il gioco è fatto.

Il link ha un eccellente tutorial su come iniziare con mercurial.

Ci sono alcune società di hosting SVN che offrono un account gratuito per uno o due sviluppatori e non richiedono che il tuo codice essere pubblico Controlla la tabella collegata per $ 0, OSS richiesto = NO. Conto al momento nove fornitori che soddisfano questi criteri.

Mentre puoi sicuramente ospitare il tuo repository molto facilmente, ci sono alcuni vantaggi che derivano dall'uso di un provider:

• Puoi accedere al tuo codice da qualsiasi luogo senza alcuna configurazione aggiuntiva.

• Mantenere il tuo codice off-site ti protegge da crash del disco rigido, incendi, ecc.

• Basso sovraccarico amministrativo.