Comment mettre en page les dossiers localement et dans SVN lors de l'utilisation de l'éclipse

Question

Je travaille avec eclipse et SVN depuis de nombreuses années dans des équipes à partir d'un seul développeur jusqu'à 12 ans et j'ai toujours été l'un pour l'installation de notre structure de dossier. J'ai réussi à le faire fonctionner d'une certaine manière, mais j'ai l'impression que mon dossier de mise en page est loin d'être optimale. Il est difficile de dire ce que mon dossier standard de mise en page ressemble, parce qu'il avait l'air très différent à chaque fois.

Je viens juste de commencer un autre projet important, maintenant, et je veux le faire de la manière la plus professionnelle de ce temps.

Faits sur le projet

Ceux-ci sont faits en ce moment:

• Tous les développeurs vont travailler avec Eclipse
• Certains seront à l'aide de Subclipse pour intégrer SVN dans Eclipse, d'autres l'utilisent clients externes comme Tortoise SVN ou svnX
• nous sommes en train de développer sur Windows et Mac OS
• nous sommes à l'aide de ant pour automatiser la construction et les tests junit
• il y aura plusieurs projets interdépendants:
  • une bibliothèque écrite en pur java, il fonctionne sur tous connu des plates-formes java
  • plusieurs applications pour plusieurs java plattforms (J2SE, J2ME, android...). Toutes ces applications dépendent de la bibliothèque mentionné avant

Quoi faire avec .projet?

Je suis toujours pas sûr que de commettre ces fichiers généré par eclipse (comme ".projet" et ".classpath"). En avant de projets, parfois, nous les avons mis dans le SVN, parfois, nous n'avons pas, et les deux approches a utres avantages et des inconvénients. Une fois, nous avons même engagé l'ensemble de l'espace de travail, mais cela semblait être une mauvaise idée.

Un concept clé que je ne suis certainement manquant est comment Eclipse gère son espace de travail. Par défaut, l'ensemble du projet se trouve à l'intérieur de l'espace de travail-dossier, mais il peut y avoir des projets qui sont externes, qui sont liés d'une certaine magie de la façon que je ne comprends pas.

Possible dossier layouts

Je ne suis pas sûr comment à disposition du projet au niveau local et sur le référentiel. Je pense qu'il y a trois possibilités:

• l'espace de travail est un sous-dossier de ma copie de travail locale (comme c:\code\myWorkingCopies\projectXyz\trunk\workspace)
• mon espace de travail EST ma copie de travail (j'utilise c:\code\myWorkingCopies\projectXyz\trunk\ comme espace de travail)
• Mon espace de travail est quelque part (c:\code\workspace) et ma copie de travail à un autre endroit c:\code\myWorkingCopies\projectXyz\trunk) et j'ai ces projets externes
• d'autres idées?

Ce type de réponse que je cherche?

Un mannequin structure de dossier, peut-être quelque chose comme ça (dois-je viens de répondre à ma propre question?):

• tronc
  • projets
    • projectA
    • projetb

Avec un soupçon de ce que à la caisse où, comme ça:

• la caisse trunk/projets c:\code...)

Et quelques lignes directrices comme

• ne jamais télécharger des fichiers de type x,y,z,...

Answer 1

Les espaces de travail et les bases de données ne devraient pas être liées.

L'espace de travail est vraiment juste où Eclipse magasins un tas de paramètres. Les fichiers de projet peuvent (et le font habituellement) vivent dans l'espace de travail, mais comme vous le savez, ils peuvent être importées à partir d'une source externe--l'importation est juste un lien logique.

Vous pouvez créer autant d'espaces de travail que vous le souhaitez à des fins spécifiques; vous pouvez même importer des projets dans un espace de travail dans un autre si vous avez eu raison de le faire.

Le SVN de mise en page doit être distincte de la façon dont votre espace de travail est défini. Ils risquent de finir à la recherche semblable, mais ça ne signifie pas qu'ils sont en fait la même. Je le recommande à chaque projet Eclipse avoir son propre projet SVN, de sorte qu'au lieu d'avoir

• http://myrepo
  • myworkspace
    • tronc
      • projectA
      • projetb
    • tags
    • les branches

vous avez

• http://myrepo
  • projectA
    • tronc
    • tags
    • les branches
  • projetb
    • tronc
    • tags
    • les branches

Ce que cela fait pour vous est de vous donner la flexibilité à la disposition de votre espace de travail entièrement distincte de la façon dont le référentiel est structuré. Vous serez en mesure de vérifier les projets individuels dans l'espace de travail sans avoir à la caisse de la totalité de la base de code. Vous serez en mesure d'avoir des projets vérifié sur des branches de développement tandis que d'autres sont sur le tronc, vous pouvez annuler les modifications apportées à un projet tout en laissant l'autre seul, et ainsi de suite.

La dernière question à propos de laquelle les artefacts de vérifier dans le SVN est une question de goût. Je vous recommande de vérifier en quoi les artefacts sont universels à travers l'équipe de développement. Si l'Éclipse est la norme IDE, aller de l'avant et de vérifier dans les .projet de et de .classpath fichiers de sorte qu'un nouveau développeur sera en mesure de caisse et de construire immédiatement. Si certains plugins sont universels et ont des fichiers de configuration qui leur est propre, aller de l'avant et de vérifier ceux aussi bien. D'autre part, tout ce qui n'est pas partagé entre l'équipe de développement ne devraient pas figurer dans le référentiel.

Espérons que cette aide.

---

MODIFIER

L'expérience m'a appris que les seules choses qui devraient aller dans le contrôle de code source sont la véritable source des fichiers. Configuration et des fichiers de configuration doit être régénéré par le développeur lors de la configuration d'un nouveau projet.

Answer 2

Nous avons une semblable installation (Mac, Linux, et les utilisateurs de Windows) et notre structure de dossier est:

• tronc
  • code
    • projectA
    • projetb

Nous n'vérifier dans le .projet .paramètres, et .classpath fichiers ainsi le code, mais PAS les espaces de travail. Les véritables pièges ont à voir avec le build path. Si vous parvenez à résoudre ces il n'y a pas de maux de tête et aucune condition à laquelle répertoire de choses ont besoin d'être vérifié dans.

Quelques conseils:

1. Si vos projets de référence les uns des autres assurez-vous qu'ils font référence les uns aux autres à l'aide de l'onglet "Projets" de la construction de chemin d'accès. Cela permet de garder toutes les références à d'autres projets relatifs (../projectA plutôt que /opt/trunk/projectA qui va casser les autres peuples de projets).
2. Si vous avez des bibliothèques externes que vous faites référence, de créer des bibliothèques et tout le monde en créer un avec le même nom. Nous utilisons JBoss afin de nous faire tout le monde de créer un utilisateur appelé bibliothèque de JBoss qui références les pots dans leur local d'installation de JBoss. De cette façon, il n'a pas d'importance où votre JBoss est installé, aussi longtemps que vous avez que l'utilisateur de la bibliothèque, vous serez bon d'aller. Votre projet de référence de l'utilisateur nom de la bibliothèque, mais le réel de l'utilisateur informations de la bibliothèque locale pour chaque utilisateur.
3. Assurez-vous que tout le monde sait sur les conseils de numéro 1 et 2. Les seules fois où les choses se faire défoncer jusqu'ici, c'est quand quelqu'un oublie de faire des références via l'onglet Projet, au lieu de juste un lien vers le pot directement.

Tout cela fonctionne avec Eclipse, SVN plugins ou sans.

Answer 3

Dans les deux Macromedia Dreamweaver et Eclipse, j'ai été en procédant de la manière suivante:

Working folder: 
C:\Development\
    \ProjectA
    \ProjectB
    \ProjectC

Chaque projet a son propre référentiel, et chaque caisse est seulement de l' /trunk/.

Remarque: Pour Eclipse, de ne pas créer un Dépôt SVN du projet, il suffit de créer le "Java Application" ou "PHP App" projet comme vous le feriez normalement, et utiliser un programme externe pour le faire passer à la caisse dans ce dossier. L'éclipse sera alors automatiquement détecter le .svn de l'information et de vous permettre d'utiliser le SVN outils, tout en utilisant le bon espace de travail.

Answer 4

J'utilise et recommande fortement de la structure du référentiel quelque chose comme:

• Projets
  • ProjectA
    • tronc
      • java
      • html
      • docs
      • conf
• Vendeur
  • junit
    • actuel
    • 1.1
    • 1.2

Sur le disque utilise une mise en page comme:

c:\dev\
   \ProjectAtrunk\
   \ProjectBbranch4\

En travaillant de cette façon, vous êtes les branches et les tags sont à proximité de votre troncs et vous avez peu de chances de dépendre de la structure des projets dans votre référentiel de référence des bibliothèques externes. Toutes les références au code de l'extérieur du projet tronc doit utiliser les références externes.

Tout cela signifie que vous êtes plus susceptibles d'être en mesure de garder la maxime de vérifier le tronc est tout ce que vous devez être en mesure de construire votre projet. Code partagé est conservé et géré comme un projet distinct et référencé avec des externes.

Vous êtes plus en mesure de voir les changements sur un projet de tronc et de voir l'historique complet de votre projet sans déchets. Vous êtes moins susceptibles d'avoir des modifications à votre projet qui ne sont pas visibles lorsque vous regardez votre historique de révision sur le tronc.

Lors de la libération, faire usage de la stabilité des branches et svn-fusion.

Answer 5

Ickster dit "...mais comme vous le savez, ils peuvent être importées à partir d'une source externe--l'importation est juste un lien logique."

En fait, ce n'est pas tout à fait vrai. Un import effectue une copie, alors qu'une ressource liée est un lien vers la source extérieure de la structure. Voir: Des Ressources Liées et La Création De Ressources Liées