Discussion :

[_KB_]

Bonjour à tous,

Y en a t'il parmi vous qui utilise l'option Configure Branches/Tags avec le plugin subclipse ?
Après avoir consulté l'aide et fait quelque essais, je ne suis pas sur de comprendre l'intérêt de cette option

Je m'explique. Quand je veux créer une branche ou tag je le fais à partir du svn repository (afin de créer une branche ou un tag avec un point de départ maitrisé, c'est à dire archivé par svn dans le repository).

Si j'ai bien suivi ce que m'indique l'aide, l'intérêt de Configure Branches/Tags (accessible par la commande team) et de pouvoir indiquer des repères sur chaque révision. Par exemple la révision 50 correspond au tag TOTO et la révision 49 à la branche TITI.

Dans ce cas là quelle est la bonne utilisation de cette option?

1: création d'un tag
2: switch du working copy vers le nouveau tag (ou check out vers nouveau projet à partir du tag)
3: ajout d'une étiquette à partir du working copy à l'aide de Configure Branches/Tags

Je pense que quelquechose m'échappe.

Merci de m'éclairer.

[_KB_]

Je pense avoir compris le fonctionnement de l'option mais il me reste un truc à régler. J'ai remarqué que la configuration de branches/tags modifie le fichier .project du projet eclipse. Faut il faire un commit à chaque configuration d'une branche ou d'un tag ? Si oui, ce n'est pas pratique...

Merci de vos retours.

[julien-blaise]

Salut,

Je n'ai jamais utiliser cette option, je préfére passer par le serveur pour cette gestion.
Par contre, si cette manip modifie le .project, tu penses pas que ça va relier ton projet Eclipse à ta nouvelle branche ou tag ?

Le mieux dans ce cas, ne serait-il pas de créer un nouveau projet (ou faire une copie d'un projet existant) pour faire la branche/tag ?

A+

[_KB_]

Merci pour ta réponse.
Je ne peux pas me permettre d'archiver le .project de toute manière
Donc à moins d'avoir d'autres retours, j'abandonne cette option pour le moment ...

Par contre tu dis passer par le serveur. Tu connais une commande pour remplacer ce que je cherche à faire avec subclipse ?

Merci.

[Laurent.B]

Bonjour,

Sur quel OS tu es ? Car sous Windows avec Tortoise, c'est assez simple de gérer les branches / tags.

D'autre part, ce qu'il faut comprendre, c'est qu' à la base SVN ne fait pas de distinction entre le trunk, les branches et les tags. C'est assez fictif et simplement conventionnel tout ça. Ce qui signifie que ces répertoires contiendront ce que tu y placeras. A toi d'en faire bon usage, c'est à dire de garder le trunk pour la version de base, les branches pour des versions qui seront réintégrées ultérieurement dans le trunk et les tags pour figer des versions quelconques du trunk ou même des branches si ça te chante mais donc en s'interdisant de commiter dessus.

Quant à ton histoire de .project qui est modifé lors de la création de branches, faudrait voir ce qu'il contient pour changer ainsi car a priori, ce n'est pas la création de branche qui est censée modifier quoi que ce soit. Eclipse se débrouille peut-être de rectifier des références relatives à des éléments externes dans ce fichier mais c'est assez étonnant qu'il agisse automatiquement dans ce cas précis... Ca donne quoi si tu compares les deux versions ?

Personnellement, je n'ai pas de problème pour versionner le .project avec ou sans Eclispe. Il est versionné dans le projet du trunk ? Ou est-il référencé comme devant être ignoré ?

[_KB_]

Hello,

Bonjour,

Sur quel OS tu es ? Car sous Windows avec Tortoise, c'est assez simple de gérer les branches / tags.

Je suis sur Windows XP. Utiliser Eclipse est une exigence, c'est notre outil de travail. Je ne peux pas installer Tortoise.

D'autre part, ce qu'il faut comprendre, c'est qu' à la base SVN ne fait pas de distinction entre le trunk, les branches et les tags. C'est assez fictif et simplement conventionnel tout ça. Ce qui signifie que ces répertoires contiendront ce que tu y placeras. A toi d'en faire bon usage, c'est à dire de garder le trunk pour la version de base, les branches pour des versions qui seront réintégrées ultérieurement dans le trunk et les tags pour figer des versions quelconques du trunk ou même des branches si ça te chante mais donc en s'interdisant de commiter dessus.

Tout à fait d'accord là dessus

Quant à ton histoire de .project qui est modifé lors de la création de branches, faudrait voir ce qu'il contient pour changer ainsi car a priori, ce n'est pas la création de branche qui est censée modifier quoi que ce soit. Eclipse se débrouille peut-être de rectifier des références relatives à des éléments externes dans ce fichier mais c'est assez étonnant qu'il agisse automatiquement dans ce cas précis... Ca donne quoi si tu compares les deux versions ?

En réalité c'est le fichier .cproject qui est modifié et ce n'est pas à la création d'une branche, mais lors de l'utilisation d'une option qui s'intitule configure branche / tags J'ai fait quelques recherches et il ne semble pas y avoir de commande svn ou d'équivalent avec Tortoise... Lors de la création d'une branche ou d'un tag à partir du trunk, en affichant l'historique de la branche ou du tag en question, on visualise l'historique complet du point de départ d'une part, mais surtout on visualise le numéro de révision (et commentaire associé) du trunk à partir duquel on a tagué ou branché. Par contre si on fait un historique du trunk on ne voit pas la création du tag et de la branche. On ne verra que les révisions associées à des commit, move, delete sur le trunk. L'option configure branche/tag peut permettre de poser une étiquette sur le trunk et associer à un numéro de révision le tag ou la branche que l'on a créé.
Par contre j'ai remarqué que lorsque j'utilise cette option de configuration (qui ajoute une colonne "tags" dans l'historique) le fichier .cproject est modifié. Or je ne suis pas autorisé à archiver ce fichier si je n'ai pas clairement identifié comment il est utilisé.
Lorque je fais une comparaison entre la base SVN et le working copy, la seule différence est la présence d'un fichier .project et .cproject

Personnellement, je n'ai pas de problème pour versionner le .project avec ou sans Eclispe. Il est versionné dans le projet du trunk ? Ou est-il référencé comme devant être ignoré ?

les fichiers .project et .cproject sont à la racine du projet eclipse.
J'ai utilisé l'option de filtrage d'eclipse pour ne pas avoir de différence entre la base svn et la copie locale. Mais du coup je ne peux pas utiliser configure branche / tag

Merci pour ta réponse

[Laurent.B]

Ma foi... le .cproject semble venir du fait que c'est un projet C/C++ n'est-ce pas ? Il contient quoi ? Le même genre de choses que ce qu'il y a dans une .project normal ?

Si tu ne peux pas installer Tortoise, j'imagine que c'est parce que tu n'es pas admin de ton poste... Et donc pour un développeur, c'est quand même handicapant.

Bon, à mon avis, un ou deux screenshots ne seraient pas de trop

Pourquoi utiliser l'option de filtrage ? Je ne comprends pas l'intérêt.

[_KB_]

Désolé je n'ai pas eu le temps de te répondre plus tôt.
Alors voilà:

Ma foi... le .cproject semble venir du fait que c'est un projet C/C++ n'est-ce pas ? Il contient quoi ? Le même genre de choses que ce qu'il y a dans une .project normal ?

J'ai regardé, je n'ai pas clairement identifié ce que contiennent ces deux fichiers...

Si tu ne peux pas installer Tortoise, j'imagine que c'est parce que tu n'es pas admin de ton poste... Et donc pour un développeur, c'est quand même handicapant.

Je suis administrateur de ma machine. Je peux très bien installer Tortoise. Par contre nous avons une liste d'outils on va dire "officiel" pour développer et faire l'interface avec la gestion de configuration. Et tortoise n'en fait pas parti.

Bon, à mon avis, un ou deux screenshots ne seraient pas de trop

Pourquoi utiliser l'option de filtrage ? Je ne comprends pas l'intérêt.

Je filtre les deux fichiers (.project et .cproject) car lorsque je fais un checkout as project à partir d'une base SVN, eclipse indique dans le nouveau projet créé que je ne suis pas synchronisé avec la base. (petite étoile à coté du nom de projet sur le screenshot).



Lorsque je fais l'écart entre mon local et la base, le seul écart concerne ce fichier .project. En effet celui-ci n'a pas été archivé sur le serveur SVN. J'imagine que lorsque je fais un checkout, eclipse crée automatiquement un fichier de configuration .project.

Pour le point .cproject, c'est un autre cas. Il semble utilisé pour l'option qui sert à étiqueter un tronc pour identifier les tags et les branches (voir mes messages plus haut ou regarder dans le lien suivant ). Comme je peux pas archiver ce fichier, j'ai fait une croix sur cette option. Comme je l'ai dit dans mes messages précédents je n'ai pas trouvé de commande svn équivalente de toute manière. Cela permet de clarifier l'arbre du projet mais ce n'est pas absolument nécessaire, surtout si cela implique l'archivage d'un fichier particulier.

J'espère que c'est plus clair.
Je pense que seul un utlisateur de SVN via eclipse pourra m'aider ...

[Laurent.B]

Je suis utilisateur de SVN sous Eclipse et de Tortoise et je peux te dire que j'ai toujours les deux sous la main tout simplement parce que les possibilités ne sont pas toujours identiques.

Donc sinon, je pense avoir compris tes contraintes et a priori, il n'y a rien de compliqué mais il va falloir faire des choix.

Si tu ne peux pas créer ta branche c'est effectivement parce que SVN détecte une différence entre le projet local et celui qui est sur le repository. Du coup l'option de création doit être conditionnée par rapport à ça et même si théoriquement ça ne devrait pas franchement gêner, c'est ainsi (sous Tortoise il est probable que ça fasse la même chose mais bon...).

Donc appliquer un filtre "Eclipse" ne sert effectivement à rien puisque ça ne doit faire que masquer le problème. Le status SVN du projet est le même, le filtre n'as pas d'impact même si visuellement il te le fait croire. C'est la même différence qu'il peut y avoir entre une vue logique (comme Package) et une vue physique (comme Navigator et encore...).

Donc, les possibilités sont les suivantes (que tu soies ou non autorisé à les mettre en application) :

Versionner le ou les fichiers créés lors de l'import à la condition que ceux-ci puissent convenir également aux autres intervenants sur le même projet. Autrement dit, qu'ils ne contiennent rien qui soit dépendant de ta propre machine tels que des liens absolus.

ou

Mettre en "ignore" SVN les fichiers qui ne doivent pas être versionnés, puis commiter le répertoire qui les contient. Et donc tout le monde pourra avoir son ou ses propres fichiers .project ou .cproject et personne ne pourra les commiter. Peut-être même que la mise en ignore de ces fichiers est un oubli ... ? Si ce n'est pas le cas, alors cela signifie peut-être qu'Eclipse n'était pas l'EDI de départ et comme ces fichiers sont propres à un environnement Eclipse, ils ne sont donc pas identifiés comme à versionner ou à ignorer.

Voilà, donc une fois que tu sauras quelle option prendre, ton projet pourra être parfaitement synchrone et tout devrait rentrer dans l'ordre.

[_KB_]

Merci de prendre le temps de me répondre

Si tu ne peux pas créer ta branche c'est effectivement parce que SVN détecte une différence entre le projet local et celui qui est sur le repository. Du coup l'option de création doit être conditionnée par rapport à ça et même si théoriquement ça ne devrait pas franchement gêner, c'est ainsi (sous Tortoise il est probable que ça fasse la même chose mais bon...).

Non je peux créer une branche, le problème n'est pas là. Je ne peux pas utiliser cette option, qui semble nécessiter un fichier particulier (le .cproject).

Donc appliquer un filtre "Eclipse" ne sert effectivement à rien puisque ça ne doit faire que masquer le problème. Le status SVN du projet est le même, le filtre n'as pas d'impact même si visuellement il te le fait croire. C'est la même différence qu'il peut y avoir entre une vue logique (comme Package) et une vue physique (comme Navigator et encore...).

Tout à fait d'accord, je masque le problème. Mais lorsque je fais une modif sur un fichier source et que je souhaite faire un commit derrière, je ne suis pas obligé de "décocher" les fichiers .cproject et .project (tous deux présent en local et pas sur la base svn). Dans la capture ci-dessous je n'ai pas filtré le fichier et voici ce que j'obtiens lorsque je veux commiter une modif:


Je pense que je "loupe" quelquechose à la création de ma base SVN via eclipse.
Lorsque je veux partir d'une base vierge voilà comment je procède:
1/ création du repository (svn admin create mon_repository)
2/ ouverture d'eclipse. Création d'un nouveau "Repository Location"
3/ création des répertoire tags, branches, trunk à partir du SVN repository perspective.
4/ import des fichiers de mon local vers le trunk (à partir du SVN repository perspective, clic droit sur le trunk vide puis import)

Maintenant que j'ai ma base je veux travailler dessus. Je prend mon trunk et je fais un check out as project
J'ai mon projet, image du trunk de ma base SVN, mais eclipse me déjà signale déjà un écart.
En faisait une comparaison, l'écart concerne le .project
Et voici le contenu du fichier:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>CAAtest4</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
	</buildSpec>
	<natures>
	</natures>
</projectDescription>

Mes options:

1/ Archiver ce fichier.
2/ Filtrer ce fichier.
3/ Changer la façon dont je procède pour la création de ma base / le check out

Peut être que si tu m'indiquais comment toi tu procèdes, ça m'éclairerait.

Merci

[Laurent.B]

Peut être que si tu m'indiquais comment toi tu procèdes, ça m'éclairerait.

Si le projet présent en local n'a encore jamais été versionné, je pense que j'aurais fait un "Team > Share Project..." via un clic droit sur le projet, plutôt que import...
Mais pour le reste, je n'ai peut-être pas assez manipulé les branches et tags pour me poser ce genre de questions, désolé.

[_KB_]

Si le projet présent en local n'a encore jamais été versionné, je pense que j'aurais fait un "Team > Share Project..." via un clic droit sur le projet, plutôt que import...
Mais pour le reste, je n'ai peut-être pas assez manipulé les branches et tags pour me poser ce genre de questions, désolé.

Oui j'ai essayé le "Team > Share Project..."
En faisant ça tu archives le .project
Enfin il y a peut être moyen de le décocher quelquepart mais disons que l'intérêt d'importer plutôt que partager c'est, selon moi, de maitriser clairement ce que l'on met sur sa base.
Je suis en train de tester subversive pour voir s'il répond mieux à mon besoin que subclipse.

Merci pour le support en tout cas.

[Laurent.B]

Je t'ai expliqué qu'il n'y a pas 36 possibilités, soit tu le versionnes, soit tu le déclares comme à ignorer par SVN... Il est où le problème ?

[_KB_]

J'essaie de comprendre ce qu'il se passe réellement. Pourquoi Eclipse a besoin de ce fichier.
J'avais tenté le svn:ignore et il s'était passé quelquechose de bancal:
J'avais toujours la petite icône qui indiquait que je n'étais pas synchro avec la base, mais quand je faisais une comparaison il me signalait aucune différence. C'est pour ça que j'en été arrivé au filtrage.

En bref, le problème, c'est que je ne peux pas me permettre de faire n'importe quoi sans "comprendre" réellement ce qu'il se passe.
A partir de là je pourrai choisir entre les deux seuls solutions, à savoir: celles que tu m'as données

Je mets en résolu.

[Laurent.B]

Eclipse a besoin de son .project car c'est ce qui lui permet de savoir si le répertoire où se trouve ce fichier, est ou non un projet qu'il sait gérer et dont la nature lui est ou non familière (Java / C / C++ / ...etc).

Donc, il n'y a pas de mal à le versionner !

Relis bien ceci :

Donc, les possibilités sont les suivantes (que tu soies ou non autorisé à les mettre en application) :

Versionner le ou les fichiers créés lors de l'import à la condition que ceux-ci puissent convenir également aux autres intervenants sur le même projet. Autrement dit, qu'ils ne contiennent rien qui soit dépendant de ta propre machine tels que des liens absolus.

ou

Mettre en "ignore" SVN les fichiers qui ne doivent pas être versionnés, puis commiter le répertoire qui les contient. Et donc tout le monde pourra avoir son ou ses propres fichiers .project ou .cproject et personne ne pourra les commiter.

Est-ce qu'il y a quelque chose que tu ne comprends pas dans mes explications ?

Le .cproject, je ne le connais pas mais si c'est un fichier reconnu d'Eclipse, alors il doit être soumis aux mêmes règles que le .project.

[_KB_]

Non j'ai bien compris ce que tu as quoté, c'est pour ça que j'ai mis à résolu.
Reste à savoir s'il est préférable de l'archiver ou de l'ignorer.
Merci.

[Laurent.B]

Bien, ben je ne sais pas ce qu'il te manque pour être convaincu...

[_KB_]

Bien, ben je ne sais pas ce qu'il te manque pour être convaincu...

Que le chef tranche

[Laurent.B]

Que le chef tranche

Et que tu saches convaincre ton chef

Et sinon, je réitère sur le fait qu'avoir Tortoise comme client SVN secondaire peut être utile car justement, il permet parfois de voir des différences, là ou Subclipse n'y voit rien. Après, rien ne t'oblige à t'en servir pour commiter (mais faut quand même se méfier c'est vrai, sur le fait d'avoir plusieurs clients SVN qui ne soient pas tous dans la même version d'API, ça pourrait mettre un peu la pagaille).