Que faire avec de multiples projets, selon la même source?

C'est quelque chose que j'ai rencontré à deux reprises le mois dernier et je ne suis même pas certain comment cette phrase comme une requête Google.

Je suis en fait l'utilisation de SVN pour tout cela, mais il semble que ce doit être un problème de contrôle de version.

Nous avons deux projets et l'un d'eux est dépendant de certains de l'autre code. En raison de problèmes d'API, il n'est pas pragmatique avoir une certaine forme de lien entre les produits (et je ne veux pas avoir à configurer tous les non-programmeurs de machines pour faire ce travail).

J'imagine que si je mets une copie du code partagé dans la structure de répertoire, je vais finir d'écraser tous les fichiers de configuration qui utilise SVN. Cela signifierait que la version en charge répertoires du projet ne serait plus être en mesure de mettre à jour.

Ex:

Projet #1 doit utiliser la classe MyExampleClass, cependant, MyExampleClass est quelque chose qui est défini comme une partie, et requis par le Projet #2.

Voir: stackoverflow.com/questions/130447/...
J'ai essayé de regarder dans SVN de questions, mais je n'ai pas vraiment vu de cette situation. Accordé, comme je l'ai dit, je ne pouvais pas vraiment comprendre comment l'expression de la requête...

OriginalL'auteur cwallenpoole | 2009-03-19

  1. 11

    Regarder dans svn:externals

    Voir cette autre question pour plus de détails: stackoverflow.com/q/662898

    OriginalL'auteur Joel Coehoorn

  2. 14

    Nous avons utilisé svn:externals pointant à code partagé dans la pratique depuis quelques années maintenant. Nous avons eu quelques problèmes avec elle que vous devriez considérer avant de l'utiliser. Voici la structure que nous avons:

    root
+---common
|   +---lib1
|   |   \---trunk
|   |       +---include
|   |       \---src
|   \---lib2
|       \---trunk
|           +---include
|           \---src
+---proj1
|   \---trunk
|       +---include
|       |   \---common
|       \---src
|           \---common
\---proj2
    \---trunk
        +---include
        |   \---common
        \---src
            \---common

    La common répertoires dans les deux include et src dans un projet contiennent des définitions externes qui tirent dans les bibliothèques communes:

    c:\dev> svn pget -v svn:externals proj1\trunk\src\common
Properties on 'c:\dev\proj1\trunk\src\common':
  svn:externals : lib1 http://.../common/lib1/trunk/src
                  lib2 http://.../common/lib2/trunk/src

    Le problème que nous avons rencontré est multiforme mais pour le marquage et la ramification de notre source que les projets de changement à travers le temps. La façade de la définition que j'ai montré ci-dessus a un peu assez de graves problèmes si vous voulez avoir reproductible: les versions de

    1. Il renvoie à une dynamique de la cible trunk.
    2. Il ne fait pas référence à une révision explicites.

    Lorsque vous branche à l'aide de svn copy, les externes sont copiés mot à mot depuis qu'ils sont vraiment juste des propriétés attachées à l'objet. Certains des autres commandes svn (commit, checkout, et export) interpréter les propriétés. Lorsque vous ajoutez un projet, vous voulez vraiment préserver l'état de projet pour tous les temps. Cela signifie que vous avez pour "épingler" les externes à une révision spécifique de sorte que vous besoin de changer la façade de définition explicite de l'reportez-vous à la révision que vous souhaitez (par exemple, "lib1 -r42 http://.../common/lib1/trunk/src"). Cela résout une facette du problème.

    Si vous avez à gérer plusieurs incompatible branches de la commune de code, alors vous devez spécifier la branche que vous souhaitez explicitement avec (éventuellement) la révision.

    Inutile de dire que cela peut être un peu mal à la tête. Heureusement, quelqu'un là-bas dans la Subversion des terres écrire le svncopy.pl script qui automatise certains de ce gâchis. Nous sommes encore (et ont été) aux prises avec certaines difficultés inhérentes à l'appui de cette dans un champ déployé produit avec un tas de code partagé et un mandat de trois versions différentes dans le domaine à tout moment.

    Si vous allez vers le bas de cette route, alors assurez-vous d'envisager comment vous allez maintenir les liens dans les projets de croissance et de changement. Nous avons trouvé un peu de temps à réfléchir à un processus ira un long chemin ici.

    OriginalL'auteur D.Shawley

  3. 1

    Mettre tous les fichiers partagés dans un dossier distinct, soit dans l'un des projets ou dans une autre. Ensuite, utilisez externals pour faire référence à ce dossier.
    Le mélange des fichiers à partir de différents endroits dans le même dossier est une mauvaise idée.

    OriginalL'auteur svinto

  4. 1

    Externes, mais être conscient de ce problème:

    La Subversion de mise à jour des alias à une date

    OriginalL'auteur Jim T

  5. 0

    svn:externals vous permettront d'apporter dans des fichiers à un niveau de répertoire. Comme:

    Proj1\
  File1
  File2

Proj2\
  File3
  File4

    Puis dans Proj2 vous pouvez svn:externals Proj1, et jusqu'à la fin avec:

    Proj2\
  Proj1\
    File1
    File2
  File3
  File4

    Maintenant, si vous voulez avoir des fichiers à partir de 2 projets dans 1 dossier comme:

    Proj2\
  File1 <- from Proj1
  File2 <- from Proj1
  File3
  File4

    Puis je ne pense pas que SVN prend en charge que.

    Cependant, j'ai travaillé avec d'autres source outils de contrôle qui vous permet de "lier" un fichier unique à partir d'un projet à l'autre n'importe où vous voulez (Borland StarTeam en particulier).

    svn:externals prend en charge le fichier de liaison dans les svn 1.6. 1.6 RC3 est déjà disponible. La nightly build de tortoiseSVN est construit contre svn 1.6.
    merci pour l'info! on dirait que nous sommes toujours sur la SVN 1.5.5 ici... pas étonnant que ça ne marchait pas pour moi 🙂

    OriginalL'auteur CodingWithSpike