Pouvons-nous configurer un serveur svn sur un ordinateur local sans aucun accès réseau?
Je souhaite configurer un référentiel SVN sur mon ordinateur sans accès au réseau. Je travaille sur un code sans aucun collaborateur, donc je ne veux pas qu'il soit accessible au public.
J'ai lu ce post , mais il suggère d'utiliser des services de dépôt SVN en ligne qui donnent des dépôts gratuits. Dans ce cas, mon code sera accessible au public (comme cela est inclus dans les conditions des plans gratuits).
Je me demandais donc si je pouvais configurer un serveur local sur ma machine Windows XP à laquelle seul j'accède même si je n'ai pas de connexion Internet?
La façon la plus simple de configurer un serveur local est d'utiliser svnserve :
Subversion inclut Svnserve - un serveur autonome léger qui utilise un protocole personnalisé sur une connexion TCP/IP ordinaire. Il est idéal pour les petites installations ou lorsqu'un serveur Apache complet ne peut pas être utilisé.
En fait, vous n'avez pas besoin d'un serveur Subversion, si tout ce que vous voulez faire est d'accéder au référentiel localement, puisque vous pouvez accéder à un référentiel Subversion via un URL du fichier, comme décrit dans cette réponse :
Vous pouvez accéder au référentiel en utilisant le protocole file: // donc vous n'aurez besoin que de Tortoise SVN installé et rien d'autre. Voir cette question dans la FAQ: Est-il possible d'utiliser TortoiseSVN sans serveur?
Vous pouvez même avoir le référentiel dans le périphérique USB afin que vous puissiez emporter la source avec vous et travailler à partir d'autres ordinateurs.
Si vous utilisez TortoiseSVN , vous pouvez trouver des instructions sur Création du référentiel avec TortoiseSVN :
Ouvrez l'Explorateur Windows
Créez un nouveau dossier et nommez-le par ex. SVNRepository
Faites un clic droit sur le dossier nouvellement créé et sélectionnez TortoiseSVN → Créer un référentiel ici ....
Immédiatement au-dessus de cette page décrit également comment créer un référentiel à partir de la ligne de commande .
Cela dit, je vous recommande de consulter Mercurial ou Git comme alternative à svn. Si vous connaissez TortoiseSvn, vous trouverez TortoiseHg et TortoiseGit une transition facile, en plus il vous donne la flexibilité de travailler de manière distribuée plus tard si vous en avez besoin. Par exemple, dans le passé, j'ai utilisé des clés USB pour transférer des référentiels hg entre des machines sans accès réseau, et lorsque vous travaillez de cette façon, vous obtenez une sauvegarde gratuite dans le marché.
Serveur le plus simple (et le plus rapide), que vous pouvez utiliser pour travailler avec le référentiel local, intégré à chaque svn-client. Il s'agit d'un serveur permettant d'accéder à tout référentiel et à toute quantité de référentiels , existants sur le système de fichiers local, en utilisant le fichier de protocole: ///. Il ne fournit aucune méthode d'autorisation ou d'authentification, n'accorde qu'un accès illimité complet au référentiel sous contrôle, mais, d'autre part, il permet d'utiliser et donne toutes les fonctionnalités du système VCS en soi.
Afin d'utiliser ce serveur, vous avez dans n'importe quel répertoire vide dans n'importe quel emplacement appelez la commande CLI svnadmin avec la sous-commande et les paramètres correspondants (je ne me souviens pas, y a-t-il des programmes administratifs dans le bundle CLI-client ou non et ne peut pas vérifiez-le - je n'ai pas installé CLI svn-client, seulement TortoiseSVN, qui ont ces programmes dans le programme d'installation dans la version 1.7) - J'espère que vous pourrez le trouver.
svnadmin help montrez-nous toutes les sous-commandes disponibles, nous sommes maintenant intéressés par la sous-commande create.
svnadmin help create fournir tous les détails nécessaires pour nous
create: usage: svnadmin create REPOS_PATH
Create a new, empty repository at REPOS_PATH.
Valid options:
...
Au point de départ du premier dépôt, nous pouvons ignorer toutes les options de réglage fin et nous souvenir uniquement du formulaire principal svnadmin create REPOS_PATH, REPOS_PATH est un chemin absolu ou relatif vers un répertoire vide, prévu pour le repo. Étant donné que la plupart du temps, les utilisateurs Windows ordinaires pour les applications multiplates-formes peuvent confondre les personnes, quelle notation (barre oblique ou barre oblique inverse) utiliser dans le chemin (metoo), le moyen le plus sûr est cd vers l'emplacement, à partir duquel notre dir est visible sans long chemin - parent du futur répertoire repo ou du répertoire lui-même. Pour prévu pour repo z:\Mainavantsvnadmin create
Z:
cd \Main
et, enfin,
svnadmin create .
En conséquence, nous obtenons un référentiel vide créé dans le répertoire, qui apparaît dans l'Explorateur Windows avec une icône spéciale comme indicateur de contenu
Maintenant, chaque fois que ce référentiel est nécessaire, nous utilisons les commandes SVN habituelles, la partie URL ou les paramètres apparaissent comme file:///Z:/Main
c:\>svn ls file:///Z:/Main
branches/
tags/
trunk/
(J'ai ajouté un arbre de référentiel standard dans le référentiel).
Décortiquons cette étrange URL:
file:///, comme pour toute URL, signifie protocole d'accès, dans notre cas le protocole est spécial, et a trois, pas deux barres obliquesZ:/Mainest le chemin complet du repo avec le lecteur et le chemin à l'intérieur du lecteur, là toutes les barres obliques inverses de Windows remplacées par des barres obliques "classiques"
De tout autre point, ce dépôt n'a aucune différence avec "Big Brothers" avec des serveurs Subversion spéciaux
Essayons une réponse qui recommande des solutions génériques plutôt que spécifiques.
Tout d'abord oui, vous pouvez utiliser Subversion sur un ordinateur autonome - vous pouvez installer le serveur localement ou vous pouvez travailler avec file: //
Mais à moins qu'il n'y ait une très bonne raison pour laquelle vous devez utiliser Subversion, je dirais que ce n'est pas la meilleure solution au problème du contrôle de version local - notamment parce qu'il échoue à l'une des choses que je considère comme essentielles, à savoir vous assurer que vous le code source se trouve au moins à deux endroits (oui, même pour des choses personnelles). Je suggère donc d'utiliser un système de contrôle de version distribué (DVCS).
L'un des avantages de DVCS est que, une fois les outils installés, les référentiels sont autonomes dans un dossier et vous pouvez synchroniser le contenu entre différents dossiers contenant le "même" dépôt tant que vous avez un accès au niveau fichier. Vous avez également la possibilité de parler aux versions "serveur" de ces dépôts (qui sont soit hébergés en privé, soit disponibles en tant que service). Cela rend la vie beaucoup plus facile de tout exécuter localement.
Le DVCS présente également d'autres avantages.
Comme je l'ai déjà noté, je ne pense pas que vous ayez vraiment une solution VCS appropriée tant que votre code n'est pas sur au moins deux machines (en particulier deux disques durs distincts et idéalement dans plus d'un emplacement - bien que le clonage et la poussée pour dire une clé USB ou le stockage "cloud" (skydrive, dropbox, et al) est une autre façon qui devrait également fonctionner).
En ce qui concerne DVCS - je regarderais Mercurial (Hg) et Git et aussi Veracity . J'utilise Mercurial car c'est encore plus agréable sur windows ...
Si vous êtes des termes de services hébergés, je suis d'accord pour dire qu'il y a énormément de choses à féliciter github - mais il y a aussi beaucoup de bonnes choses à propos de bitbucket et Fogbugz/Kiln ... et la même chose est probablement vraie pour beaucoup d'autres services que je n'ai pas listé (par exemple http://beanstalkapp.com/ qui m'a été mentionné en passant sur Twitter plus tôt dans la journée)
Subversion ne nécessite pas de serveur. Il utilise un référentiel centralisé, mais ce référentiel est accessible via la méthode d'accès "fichier", ce qui signifie que vous avez simplement besoin d'accéder au système de fichiers sur lequel le référentiel est stocké. La façon la plus simple de configurer cela serait de créer un dossier quelque part sur votre disque dur, de pointer TortoiseSVN (ou un outil similaire) et de "créer un référentiel ici". De là, vous pouvez faire tout ce dont vous avez besoin pour obtenir votre code dans le référentiel.
Cependant, à long terme, il vaut probablement mieux utiliser un SCM distribué, les meilleurs candidats étant git (plus puissant, courbe d'apprentissage abrupte, fonctionne mieux sur * nix) et Mercurial (légèrement moins puissant, facile à apprendre, fonctionne également bien sur windows et * nix). Avec ceux-ci, votre copie de travail contient l'intégralité du référentiel et vous pouvez créer autant de clones (distants ou locaux) que vous le souhaitez. Vous pouvez démarrer localement et si vous décidez d'héberger le référentiel en externe, vous clonez simplement votre référentiel local existant vers l'emplacement externe et vous pouvez synchroniser à tout moment dans les deux directions. Mieux encore, car chacun de vos clones contient l'intégralité de l'historique du projet, le SCM se double d'un système de sauvegarde. Avec Subversion, si votre serveur meurt et que vous ne l'avez pas sauvegardé, votre historique est parti - avec git, vous clonez simplement votre copie de travail sur un nouveau serveur et c'est tout.
http://hginit.com/ a un excellent tutoriel pour commencer avec Mercurial.
Il y a pas mal de sociétés d'hébergement SVN qui offrent un compte gratuit pour un ou deux développeurs et ne nécessitent pas que votre code soit public. Consultez le tableau lié pour des frais de 0 $, OSS requis = NON. Je compte actuellement neuf fournisseurs qui répondent à ces critères.
Bien que vous puissiez certainement héberger votre propre référentiel très facilement, il existe certains avantages à utiliser un fournisseur:
Vous pouvez accéder à votre code de n'importe où sans configuration supplémentaire.
Garder votre code hors site vous protège des pannes de disque dur, des incendies, etc.
Frais administratifs réduits.