Comment définir un chemin d'accès au référentiel svn vers un chemin d'accès au serveur?

Question

Quelqu'un sur SO dit le contrôle de la source d'installation, cela prend 5 minutes. Cela prend des années, c'est fiddly et une douleur dans le cul! Et je ne reçois pas le flux de travail

Quoi qu'il en soit. J'ai svn installé sur server1. Serveur1 est également utilisé pour stocker tous nos projets et code source existants, qui ont maintenant été ajoutés à leurs dépôts respectifs sur server1. Nous avons trois développeurs travaillant sur les machines 1, 2 et 3. Lorsque nous ouvrons les projets de copie de travail sur le serveur 1 dans Visual Studio (avec VisualSVN), le chemin d'accès aux repos est file: /// d:/foo bien sûr commettre vous obtenez un message d'erreur qui dit fichier: /// d:/foo ne peut pas être trouvé parce que c'est sur le serveur et non sur la machine.

Comment faites-vous pointer vers le fichier: // \ server/d $/foo?

J'ai essayé

svn fichier Switch --relocate: /// D:/file foo: // \ server/d $/foo

ne fonctionne pas

Le flux de travail partie que je ne peux pas obtenir ma tête est-ce. Si je consulte une copie de travail d'un projet de classe et le compile. Dois-je déplacer la nouvelle DLL de ma copie de travail à la production? Ou est-ce que je vérifie la dll dans le contrôle de source, puis le déplace du contrôle de source à la production? Que se passe-t-il si plusieurs projets utilisent la DLL, puis-je la retirer du contrôle de la source vers un dossier auquel tous les projets sont destinés, ou la copier dans les dossiers de tous les projets. Maux de tête

EDIT: Merci pour votre contribution, je vais persévérer avec celui-ci!

Answer 1

Oui, le contrôle de la source ne prend que quelques minutes à configurer, mais comprendre comment cela fonctionne est la clé.

Pour répondre à cette question, il est probablement préférable d'expliquer le fonctionnement du contrôle de code source et ce que vous devriez en attendre.

Le livre http://svnbook.red-bean.com/ (que vous pouvez lire directement en ligne) a une explication fantastique quant à la façon dont cela pourrait fonctionner. Les premiers chapitres sont tout ce dont vous avez vraiment besoin pour jeter un coup d'œil sur les bases. Une fois que vous aurez compris les principes de base du livre, il deviendra évident que vous vous trompez dans votre implémentation.

Answer 2

Je suppose que votre utilisation de noms UNC pour que vous puissiez avoir un repo basé sur le réseau tout en utilisant un schéma file: // est le problème ici. Il devrait y avoir un serveur SVN sur la machine d'hébergement repo. Ce serait ne serait pas contacté en utilisant un fichier: // schéma.

En ce qui concerne la vérification de la sortie compilée, en bref, ne le faites pas. Ce qui est dans Subversion devrait être compilable par chaque client à partir de zéro. Les binaires compilés n'ont pas leur place dans un repo de subversion, sauf (peut-être) qu'ils proviennent d'une tierce partie et sont essentiels à la construction.

"Et si plusieurs projets utilisent la DLL, est-ce que je la retire du contrôle de la source dans un dossier où tous les projets se tournent, ou est-ce que je la copie dans les dossiers de tous les projets?" pas de réponse. Pardon.

Answer 3

Le SVN livre vous recommande ne utiliser le protocole file: // pour plusieurs utilisateurs

Choosing a Server Configuration:

Ne vous laissez pas séduire par l'idée simple d'avoir tous vos utilisateurs accéder directement à un dépôt via file: // URLs. Même si le référentiel est facilement accessible à tous via un partage réseau, c'est une mauvaise idée. Il supprime toute couche de protection entre les utilisateurs et le référentiel: les utilisateurs peuvent accidentellement (ou intentionnellement) corrompre la base de données du référentiel, il devient difficile de mettre le référentiel hors ligne pour inspection ou mise à jour. voir la section intitulé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 vous déconseillons d'accéder aux dépôts via svn + ssh: // URLs: du point de vue de la sécurité, c'est effectivement la même chose que pour les utilisateurs locaux. si l'administrateur ne fait pas attention

Answer 4

Nick:

Accroche-toi. N'abandonnez pas le contrôle du code source! Croyez-moi, la courbe d'apprentissage que vous êtes en train d'apprendre va être payante. Re: votre problème de flux de travail, vous êtes confronté à la question de savoir comment vous construisez votre logiciel. Il y a beaucoup de méthodes que vous pouvez utiliser, mais les bases sont les suivantes. Lorsque vous compilez votre application, assurez-vous que vos artefacts (.exe, .dlls, etc) sont marqués avec svn: ignore (dans Tortoise, vous dites simplement "add to ignore list"). Cela empêchera SVN de vérifier vos builds. Vous ne voulez pas que vos artefacts de construction soient archivés à partir des copies des développeurs car cela prend beaucoup de place et crée beaucoup de conflits.

Vous avez deux options, mais je vais faire une suggestion pour votre flux de travail en fonction de ce que vous me avez dit:

Construisez votre DLL en dehors du contrôle de code source. Dans SVN, configurez un répertoire pour votre code "libéré" - pour moi, c'est un répertoire appelé "releases" sous mon projet. Ensuite, lorsque votre DLL est testée et vérifiée, donnez-lui un numéro de version et cochez-le dans votre section "releases". Dites à vos développeurs qu'il existe une nouvelle version de la DLL partagée qu'ils peuvent utiliser et dites-leur quels sont les changements. Ils peuvent ensuite dérouler votre DLL à volonté et l'intégrer dans leur code. Une fois que vous vous sentez à l'aise avec SVN (cela arrivera!), Vous pouvez passer à des choses comme Hudson ou CruiseControl.NET, qui se trouvent sur votre réseau et surveillent SVN pour les changements. Lorsqu'ils détectent un changement, ils construisent automatiquement votre logiciel en fonction de la manière dont vous le spécifiez. Cela rend toute cette copie autour des affaires totalement automatique. Même sans CCNET, vous pouvez créer un "fichier de construction" en utilisant nAnt ou MSBuild (j'utilise personnellement MSBuild) qui fera tout ce travail de copie selon la méthodologie que vous aurez choisie, donc vous n'aurez pas à faire tout ce que vous voulez. ce truc manuel chaque fois que vous voulez faire une construction.