2010-04-07 5 views
5

Je suis nouveau dans la configuration de subversion mais à l'origine, lorsque j'ai créé un référentiel, tous les membres de mon équipe pouvaient mettre à jour et valider sans problème. Il y avait un problème avec cela, nous avons donc décidé de le recréer, mais maintenant seulement je peux y apporter des modifications. Et mon nom d'utilisateur/mot de passe ne fonctionne pas sur leurs ordinateurs, donc je suis sûr que c'est quelque chose d'évident et stupide, mais je ne sais pas assez pour savoir ce qui le cause.Problème Subversion - Activer l'accès

Les fichiers passwd et svnserve.conf sont identiques au référentiel d'origine qui a fonctionné pour tout le monde.

Des idées? Merci d'avance.

+4

Passer à la panne du serveur? - n'est pas une question de programmation –

+0

Est-ce que tout le monde a accès à la machine sur laquelle le référentiel existe? Ont-ils un accès svn (sont-ils dans le groupe svn dans/etc/groups, si c'est nécessaire?) Y a-t-il des messages d'erreur dans le journal système? – WhirlWind

+0

Quel est le système d'exploitation de la machine hébergeant votre référentiel? Accédez-vous via le serveur Web? svn + ssh? – Dima

Répondre

0

J'ai eu un problème comme celui-ci. À la fin, j'ai fini par supprimer tous les utilisateurs et groupes, puis les recréer tous.

0

Si votre référentiel se trouve dans une boîte Linux et que vous utilisez svn + ssh, je pense que la définition d'autorisations sur le référentiel peut résoudre votre problème. Idéalement, vous souhaiterez créer un groupe pour tous les utilisateurs qui ont besoin d'accéder au référentiel et rendre le référentiel accessible en écriture pour ce groupe. Si vous ne pouvez pas créer un groupe, vous devrez le rendre accessible en écriture.

Vous pouvez également configurer le serveur Web Apache pour accéder à votre référentiel via le Web. Cela fonctionnera aussi avec le tortoissvn.

+0

Je l'ai rendu accessible en écriture pour voir si cela fonctionnerait, et cela ne me donne pas de chance:/ – Calvin

+0

Assurez-vous que vous utilisez svn + ssh pour que l'authentification soit faite par ssh et non par svnserve ... Ne pas savoir quoi d'autre à vous dire ... – Dima

0

Un pare-feu est-il actif sur les autres ordinateurs? désactivez-le et réessayez. Si cela fonctionne, définissez une exception appropriée. Peut-être alors également envisager réactivant le pare-feu sur votre machine :-)

1

Vous aurez envie de se concentrer sur les choses qui ont changé ...

svn + ssh exige que vous êtes connecté au système de dépôt et que auth-access = write (dans svnserve.conf), du moins c'est comme ça que je l'ai vu mettre en place. Est-il possible que des sessions aient été initialement enregistrées dans le référentiel, et qu'elles ne sont plus là?

Il y a un tutoriel sur la configuration:

« Guide d'installation pour Linux Subversion Server, en utilisant l'accès client SSH (en utilisant le protocole svn + ssh avec svnserve -t)

Gunther Strube (SGB @ utilisateurs .sourceforge.net, Mars 2004) »

mais vous avez probablement déjà su que ;-)

1

vous pouvez avoir à supprimer le cache d'authentification svn locale sur chaque machine accédant au serveur svn pour forcer chaque utilisateur authentifier à nouveau. Le cache d'authentification est dans le répertoire de l'utilisateur: Linux: /home//.subversion de Windows: c: \ Documents and Settings \ .subverison

La plupart des outils client svn ont une option de débogage - s'il vous plaît activer et la révision le résultat. J'ai vu des clients qui ne gèrent pas très bien l'authentification NTLM. Le serveur svn doit toujours offrir l'authentification BASIC au-dessus de NTLM.