Prise en charge d'un seul repo SVN dans différentes hiérarchies de dossiers

Question

J'ai donc un projet qui relie des fichiers et des dossiers éparpillés dans mon système de fichiers. Logiquement, tous ces fichiers appartiennent à un seul projet et donc à un seul dépôt SVN, mais je ne peux pas les combiner en une seule hiérarchie de dossiers parce que les programmes impliqués sont tous codés en dur pour enregistrer leur code source dans des répertoires spécifiques.

Je ne pense pas être le premier à être confronté à un tel scénario, j'espère donc qu'il existe une solution simple. J'ai envisagé quatre approches, mais elles ont toutes des inconvénients. Existe-t-il une autre approche que je n'ai pas envisagée ou, à défaut, quelqu'un peut-il m'éclairer sur la meilleure approche à long terme ?

Voici les approches que j'ai envisagées :

1. Vérifiez le sous-dossier approprié du repo SVN dans chaque dossier système. Probablement le plus simple techniquement, mais je n'aime pas qu'un grand nombre de commits séparés deviennent nécessaires pour constituer ce qui pourrait être un seul commit "logique". Même chose pour les mises à jour.
2. Garder un checkout SVN dans un seul endroit et utiliser un programme pour synchroniser la hiérarchie SVN et les dossiers du système. Cela rend l'utilisation de SVN un peu plus simple, mais il y a plus de pièces mobiles. Il est également assez facile d'écraser un travail non engagé si quelqu'un synchronise dans la mauvaise direction.
3. Checkout SVN unique, utilisation de jonctions/symlinks vers les dossiers système. Sur la base de mes tentatives et de quelques recherches sur le web, cela semble être techniquement impossible à l'heure actuelle. Cela semble également un peu fragile.
4. Je pourrais peut-être faire le chemin inverse et changer les dossiers de programmes codés en dur pour qu'ils soient des liens symboliques/jonctions vers des sous-dossiers de mon checkout SVN. Cela semble encore un peu fragile : les mises à jour logicielles pourraient remplacer le lien symbolique, ou un ou plusieurs des programmes pourraient ne pas aimer les liens symboliques non plus.

Veuillez noter que certaines des personnes qui travailleront avec ce référentiel ne sont pas des développeurs, donc j'aimerais garder les choses aussi simples que possible pour eux. Notez également que c'est un environnement Windows, et que nous utilisons généralement TortoiseSVN. Git/mercurial/etc ne sont pas une option, la politique de l'entreprise exige que SVN soit lié à notre processus de publication.

En suivant l'approche "la chose la plus simple qui puisse fonctionner", le numéro 1 semble être la solution. Mais peut-être (avec un peu de chance ?) y a-t-il quelque chose qui m'échappe ?

Answer 1

Puisque personne ne s'est exprimé à ce sujet, je dirai simplement que j'ai fini par choisir la porte n° 1. Cette "solution" est la plus simple à comprendre pour un nouveau venu, sans rien de subtil qui pourrait casser et causer du tort ou de la confusion. Les commits multiples peuvent être un peu ennuyeux, mais j'ai constaté dans la pratique que nous ne mettons généralement à jour/commitment qu'un ou deux emplacements à la fois de toute façon.

Il convient également de noter que certains IDE peuvent faire abstraction de ce problème. Si votre environnement de développement prend en charge les projets ou les solutions qui tirent des fichiers à partir d'emplacements disparates, il est probable que les plugins SVN le fassent aussi. Visual Studio + AnkhSVN peut le faire, par exemple : Ankh divisera simplement votre " unique " commit en plusieurs commits réels vers SVN. Cela ne s'applique pas vraiment à mon scénario, mais peut-être que cela aidera quelqu'un d'autre.