est-il sûr pour plusieurs ordinateurs pour accéder simultanément à un référentiel SVN stocké sur un système de fichiers partagé?
Je construis une application dans laquelle chaque machine client Windows possède un ensemble de fichiers de travail local et peut se synchroniser périodiquement avec le reste de l'équipe. D'un point de vue du serveur, j'aimerais ne rien faire sur rien, sauf un point de montage partagé Windows. Est-ce que le fichier SVN: // protocole d'URL prend en charge les systèmes de fichiers partagés ou supposons-il que le système de fichiers est local?
the Subversion Docs mention des problèmes avec BDB et FSFS dans des environnements Win9x, mais ce n'est pas clair pour moi si des référentiels accédés simultanément via File: // Les URL sont en sécurité dans des versions plus récentes de Windows (ou d'autres systèmes d'exploitation, à ce sujet).
edit L'application que je suis construit utilisera directement SVN, donc je suis disposé à construire un environnement relativement contraint si cela permettra un environnement de collaboration partagé concomitable sûr.
7 Réponses :
Deture en haut de ma tête (et je n'ai pas pu trouver d'informations en ligne), je penserais que si vous utilisez un client SVN prenant en charge le fichier: // protocole ( Tortoisisesvn , par exemple), il devrait fonctionner correctement.
Cependant, et malheureusement, je ne trouve pas le document, je me souviens de certains problèmes avec le fichier: // protocole et svn. Si possible, je suggérerais de mettre en place un serveur SVN ( Visuelsvn fonctionne très bien et est facile à configurer). que de s'appuyer sur une action de Windows.
EDIT: J'ai trouvé Cette discussion sur Stackoverflow. Il semble qu'il n'y ait pas de problème à l'aide du protocole de fichiers.
edit 2: Le lien de Neil est ce que j'avais lu dans le temps de retour et décourage le protocole de fichiers. Toutefois, si vous utilisez le fichier: // protocole signifie la différence entre l'utilisation et l'utilisation de la commande source, je recommanderais au moins d'utiliser cela. Un certain contrôle de la source est meilleur que rien.
Je suis d'accord avec utiliser VisualSvn sur une part.
Je ne suis pas d'accord avec votre deuxième édition - le contrôle de la source peu fiable est pire qu'aucun du tout.
Les documents de la tortue SVN se découragent fortement - voir Ce lien . .
résumer:
fichier: // accès est destiné à local, accès mono-utilisateur seulement, en particulier Test et débogage.
Ce sont les Docs Tortoisisesvn, pas les Documents SVN eux-mêmes. Je me demande si c'est une limitation / une opinion des gars TortoiseSVN, ou un problème avec SVN elle-même. En outre, je suis prêt à faire beaucoup de concessions autour des restrictions environnementales; Si je peux trouver un ensemble étroit d'exigences que faire travaille, je vais vous contraindre avec plaisir à eux (en supposant que l'une des exigences ne soit pas "Exécuter un processus de serveur").
Je soupçonne en quelque sorte que les développeurs de tortue connaissent un peu plus de subversion que vous ou moi. La tortue est construite sur le code de subversion afin que je suppose que c'est une limitation de base de subversion.
Ils en savent certainement plus que moi, mais je ne serais pas surpris que leurs recommandations soient pour une utilisation assez générale. Je suis prêt à faire beaucoup de concessions pour éviter d'écrire mon propre code de partage de fichiers distribué, alors je suis plus intéressé par ce qui est possible de faire en toute sécurité, plutôt que ce qui est recommandé.
Eh bien, je pense que vous faites une grosse erreur. L'utilisation d'un logiciel mono-utilisateur sur les actions Windows par plusieurs utilisateurs a toujours été portée avec des problèmes. Mais ce sont vos funérailles.
Entendu. Ce n'est pas clair pour moi que Svn + File: // est "logiciel mono-utilisateur", cependant. Certains systèmes de fichiers distribués prennent en charge le verrouillage et, avec cela, il est certainement possible de construire une solution correcte. Je ne suis pas sûr si SVN est une de ces solutions, cependant.
De l'expérience personnelle, je ne ferais pas cela! Il suffit de configurer un serveur. Ce n'est pas difficile et vous fera économiser de nombreux maux de tête.
Juge: Quelles expériences parlez-vous? Dans mon environnement, je ne peux pas déployer un serveur, donc ce n'est pas une option.
@Patrick: puis configurez un serveur dans une machine virtuelle et exécutez cela sur une machine.
Je pense que la phrase "Configurer un serveur" fait fuir les gens qui croient. Tout ce que nous parlons ici, c'est exécuter SVNserve ou un module Apache sur un système quelque part quelque part. Vous pouvez le mettre sur votre propre bureau si vous le souhaitez (non recommandé; mettez-le sur le fichier de fichiers que vous envisagiez d'utiliser pour fichier: //). SVN prend très peu de ressources système, elle n'a pas besoin d'un système dédié.
@meadow: Vous avez probablement raison du terme "serveur". Permettez-moi d'ajouter que cela ne nécessite même pas Apache. Le protocole svn: est bien, même sans. (L'avantage d'une machine virtuelle est qu'il est facile de le déplacer. C'est pratique lorsque vous n'avez pas assez de ressources matérielles pour exécuter une machine dédiée ou lorsque vous n'êtes pas autorisé à modifier une version existante.)
@RMeAdor: Je suis complètement d'accord. Cependant, comme vous l'avez dit, "Configurer un serveur" définit les cloches d'alarme, de sorte que le produit que je développe est conçu pour fonctionner dans un environnement sans serveur, dans lequel le seul espace de collaboration est partagé sur disque.
@SBI: Pour être clair, je envisage d'utiliser SVN / IN / THE PRODUIT, et non / pour construire / le produit. Nous utilisons déjà avec plaisir à GIT (sur Sedoule.com , qui rochers) pour SCM. Notre produit possède des besoins spécifiques de collaboration et notre processus de vente exige une option "sans serveur" pour nos clients, dans laquelle il n'y a pas de processus de serveur distinct requis pour activer ces fonctionnalités. Cependant, nous pouvons compter sur un mont CIFS existant (sur lequel nous n'avons aucun contrôle, et nos clients ne veulent pas affirmer le contrôle). Nous considérons avec SVN puisqu'il s'agit d'une belle abstraction et évolue bien les déploiements complets du serveur.
@Patrick: Je n'ai pas compris que SVN était censé être utilisé dans le produit. Désolé.
Je pense que vous vous préparez à des problèmes avec cette approche. Windows CIFS (le protocole de partage de fichiers Windows) a beaucoup de problèmes connus avec la modification et la modification simultanée. Il va donc être lent, soit lent, à la fois.
Un grand,
Je suis parfaitement heureux avec "chien lent", comme il s'avère. Même "chat lent" serait ok. Juste pas "dangereux". Je comprends que la mise en place d'un serveur est une meilleure approche, mais ce n'est pas une option pour ce produit, malheureusement.
La façon dont nous l'avons fait sous Windows était d'utiliser Apache pour servir nos fichiers. ici Nous sommes très heureux avec cette configuration.
Ou vous pouvez avoir un outil le faire pour vous: le serveur VisualSvn.
C'est bon frère ...
J'ai été là. J'ai aussi utilisé le système de fichiers pour partager le "serveur SVN" entre deux machines ... La seule chose que j'ai eue a été des fichiers corrompus et de gros maux de tête ...
Installé un serveur SVN (Server CollabnetsSubversion), et tout est maintenant en cours d'exécution en douceur ... Sauf pour les fois où je le vissiez moi-même ... mais c'est une autre histoire ...
acclamations.
aldo
Quelles types de problèmes de corruption avez-vous rencontrés? Utilisez-vous BDB ou FSFS? Quelle sorte de système de fichiers utilisez-vous?
Une autre question est similaire, mais a été posée sur RE: Performance: performances de protocole de subversion
Le livre SVN vous recommande Ne pas Utilisez le fichier: // Protocole pour plusieurs utilisateurs
Choisir une configuration de serveur :
Ne soyez pas séduit par l'idée simple d'avoir tous vos utilisateurs accéder à un référentiel directement via Fichier: // URL. Même si le référentiel est facilement accessible à tous via une part de réseau, c'est une mauvaise idée. Il supprime toutes les couches de protection entre les utilisateurs et le référentiel: les utilisateurs peuvent corrompre accidentellement (ou intentionnellement) corrompre la base de données du référentiel, il devient difficile de prendre le référentiel hors ligne pour inspection ou mise à niveau, et peut conduire à un gâchis de problèmes d'autorisation de fichier ( Voir la section appelée «Prise en charge de plusieurs méthodes d'accès au référentiel»). Notez que c'est aussi l'une des raisons pour lesquelles nous avertissons d'accéder à des référentiels via Svn + SSH: // URLS - d'un point de vue de la sécurité, il est efficacement identique à celui des utilisateurs locaux qui accédent via File: //, et cela peut entraîner tous les mêmes problèmes. Si l'administrateur n'est pas prudent
Intéressant ... merci pour le lien! Je me demande quels problèmes de corruption sur le référentiel qui se préoccupent.
IIRC, SVN utilise des fichiers pour verrouillage et non les serrures de niveau du système de fichiers (car ils ne sont pas uniformément pris en charge entre les systèmes de fichiers et les systèmes d'exploitation). Il est possible que la condition de course existe sur une part de réseau, car les opérations de système de fichiers supposées être atomiques (c'est-à-dire bouger) ne sont pas garanties d'atomes lors de leur accès sur un réseau. Cela m'a été expliqué en profondeur à un moment donné par le SVN Devs, mais j'ai peut-être oublié des détails, mais je pense que c'est le gist.
à partir d'un point de vue technique, il est parfaitement possible d'utiliser le fichier: // Protocole avec plusieurs utilisateurs:
La corruption sera Cependant, le problème réel est de savoir comment limiter l'accès à la base de données de référentiel pour ne pas accéder aux données du référentiel avec un autre outil arbitraire?
Si vous utilisez Fichier: // Tout le monde peut ouvrir chaque fichier dans votre référentiel SVN et modifier son contenu qui conduira sûrement à la corruption du référentiel.
Heck, chaque utilisateur peut supprimer tout le référentiel!
Vous ne pouvez pas limiter l'accès aux outils SVN et vous ne devez donc pas NE DOIT PAS Fichier d'utilisation: // Protocole.
Euh, je pense qu'il y a une différence entre FSFS et le fichier : protocole, non?
Avez-vous un soutien pour la raison pour laquelle la corruption ne se produira pas ou est-ce basée sur l'hypothèse (probablement légitime) que les gars SVN éviteraient de la corruption dans n'importe quel environnement?
Comme les prairies a déclaré: "Il est possible que la condition de course existe sur une part de réseau, car les opérations de système de fichiers supposées être atomiques (c'est-à-dire que le déplacement) ne sont pas garanties d'atomes lorsqu'ils sont accessibles sur un réseau.", Toutefois, je ne sais pas avoir une idée de cette question.
Quel est le problème que vous essayez réellement de résoudre / les contraintes que vous devez travailler?
Bonne question. Je construis une application Windows Desktop avec des fonctionnalités de collaboration. L'application doit être exécutée dans un environnement dans lequel le seul support de communication partagé garanti est un support Windows (CIFS). À l'heure actuelle, j'ai une solution qui fonctionne, mais je préférerais utiliser une abstraction comme SVN que de traiter moi-même tous les problèmes de verrouillage et de manutention de fichiers, pour un certain nombre de raisons. Fondamentalement, mon modèle de persistance est une liste des enregistrements de journal de transaction, que je rejoue lorsque l'application commence. Donc, «tous» que j'ai besoin est un moyen de maintenir en collaboration d'une liste ordonnée et des conflits inévitables.