J'ai un tas de projets avec des bibliothèques communes dans un référentiel SVN. Le référentiel a quelques branches pour les versions en production.Chemins relatifs dans les projets Delphi et ITE en particulier
Pour cette raison (vérification de plusieurs versions sur un ordinateur et réduction du temps d'échange), j'ai essayé de configurer autant que possible tous les projets avec des chemins relatifs dans le référentiel. (.... \ libraries \ common pour les formulaires dans les chemins de recherche .dpr et library). Ce n'est pas 100% idéal (il est parfois confus si vous ouvrez un fichier et naviguez dans un répertoire différent, mais cela est facilement résolu en ouvrant un fichier dans le répertoire rootdir (le répertoire avec le fichier .dpr)).
Mais maintenant j'ai commencé à utiliser l'ITE Je vois que la hiérarchie construite par l'assistant de ressources contient des chemins absolus. (drive/full/path/vers/checkout).
Est-ce que sb a une bonne solution pour faire face à cela? Spécialement le bit ITE. Existe-t-il des macros dans les chemins de recherche qui indiquent le répertoire de travail?
P.s. J'ai utilisé Visual SourceSafe donc je suis au courant des trucs habituels de subst. Je préfère une solution sans aucune action sur le changement des arbres de projet. (la modification des projets pour utiliser des chemins relatifs est ponctuelle, et donc pas si pénible)
Ps2 la situation dans les projets (pas ITE, mais les projets normaux) peut être désamorcée en fermant toujours les projets avant l'ouverture les nouvelles.
Quelle est la chance qu'ils vont corriger quelque chose dans D2009? –
Zéro, j'ai peur, vous serez chanceux s'ils corrigez-le en 2010 - et je ne parierai pas non plus sur le prochain 201x.La localisation semble être quelque chose de très faible priorité.L'assistant de ressource entière peut facilement échouer si vous utilisez des contrôles complexes (ie Developer Express et certains de JVCL), et c'est un vieil insecte, mais les bogues de dépôt et de vote sont le seul moyen de les faire remarquer. –