Discussion :

[JamesP]

Bonjour,

Je souhaite faire d utravail en équipe sous éclispe ...

J'ai proposé SVN+Subclipse, mais on me l'a refusé ...

Explications :
-> Subclipse télécharge le dossier SVN en local, puis l'envoie sur le serveur SVN a la fin de la modification ... Donc pendant un laps de temps, les versions ne sont plus identiques ...
On m'a dit HORS DE QUESTION ... donc est il possible depuis subclipse d'éditer en DIRECT et DEPUIS LE SERVEUR SVN les différents projets ? (même si moi je trouvais ca bien ... je me plie ...)

Sinon je pensais utiliser Eclipse pour travailler en direct sur des dossiers partagés par Samba ... Mais plusieurs utilisateurs peuvent ils utiliser le MEME workspace (donc le même .metadata) en même temps ???

Sinon déplacer le .métadata du workspace permettrait'il de résoudre le soucis ? si oui comment déplacer se .metadata ?

MErci a vous !

[MarneusCalgarXP]

Des outils d'édition collaborative en temps réél de fichiers ca existe, mais pas sous Eclipse, et pas gratuit non plus...

Par exemple, sous MacOSX, il existe SubEthaEdit:
http://www.codingmonkeys.de/subethaedit/

[moritan]

Et avec CVS ???

De plus ça me parait étonnant le motif de refus. Pour moi il me parait normal que lorsque le développeur tape son code, le serveur ne soit pas à jour..

Mais les outils comme CVS ou SVN, offre justement la possibilité de gérer les conflits qui peuvent survenir, c'est même le but de ces produits.

[JamesP]

Je sais je ne comprends pas vraiment non plus leur point de vue ...

Je voudrais défendre le miens mais je manque d'arguments car c'est la premiere fois que je met en place un truc CVS/SVN ...

Pas moyen de configurer SVN pour faire un "commit" automatique ?

[MarneusCalgarXP]

Pour étayer tes arguments:

Quand tu travailles avec CVS ou SVN, précise bien que tu récupères une copie des fichiers et qu'ils ne disparaissent pas du serveur pendant ce temps.

Précise également que dès qu'une modification est appliquée au code, vous pouvez la répercuter sur le serveur.

Précise aussi qu'il existe des mécanismes de vérouillage (basé sur les n° automatiques de version) pour que, lorsque 2 personnes travaillent sur le même fichier, les modifications de l'un n'écrasent pas celles de l'autre personne. exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
personne 1 "réserve" fichier A (version sur CVS : 1.10)
personne 2 "réserve" fichier A (version sur CVS : 1.10)
les 2 personnes modifient le fichier
personne 2 "valide" le fichier A (il passe en version 1.11 sur CVS)
personne 1 "valide" le fichier A (le serveur CVS détecte un conflit de versions, avertir l'utilisateur 1 et lui montre les changements entre la 1.10 et la 1.11)
La personne 1 est donc obligée à ce moment là de choisir entre
* assimiler ("merge") les changements de la personne 2
* ou les ignorer 
avant d'écrire la version 1.12 sur le serveur !

Précise enfin qu'il est possible de revenir à n'importe quel moment sur une modification précédente d'un fichier, toutes les modifications sont stockées en mémoire !

Personnellement, dans la boite, on s'est fixé comme règle : chaque soir, chaque personne "valide" (commit) les changements qu'il a apporté dans la journée si l'application compile. Tous les matins, tout le monde se synchronise avec la dernière version présente sur le CVS pour obtenir la dernière version (et avec le mécanisme de gestion de conflits, les changements non validés ne sont pas perdus si plusieurs personnes travaillent sur le même fichier)

[JamesP]

Ok je vais tenter ca ...

Ils défendent le fait qu'ils souhaitent pas avoir plusieures versions différentes en simultané de la même appli a plusieurs endroits différents ...

Et que en cas de panne réseau ca craint ...

Mais c'est surtout le point de vue de la différence de versions dans le tps ... arf ...