Bonjour,
on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec
eclipse, on ne peut pas travailler sur le même workspace, comment faire ?
L'installation de cvs est-elle compliquée ?
Merci
"Yannick" a écrit dans le message de news: 4176dfd4$0$4009$
Bonjour, on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec eclipse, on ne peut pas travailler sur le même workspace, comment faire ? L'installation de cvs est-elle compliquée ? Merci
Sous unix/linux pas compliqué (Winxxx ne sait pas)
"Yannick" <ybrunet@ifrance.com> a écrit dans le message de news:
4176dfd4$0$4009$8fcfb975@news.wanadoo.fr...
Bonjour,
on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec
eclipse, on ne peut pas travailler sur le même workspace, comment faire ?
L'installation de cvs est-elle compliquée ?
Merci
"Yannick" a écrit dans le message de news: 4176dfd4$0$4009$
Bonjour, on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec eclipse, on ne peut pas travailler sur le même workspace, comment faire ? L'installation de cvs est-elle compliquée ? Merci
"Yannick" a écrit dans le message de news: 4176dfd4$0$4009$
Bonjour, on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec eclipse, on ne peut pas travailler sur le même workspace, comment faire ? L'installation de cvs est-elle compliquée ? Merci
"Yannick" <ybrunet@ifrance.com> a écrit dans le message de news:
4176dfd4$0$4009$8fcfb975@news.wanadoo.fr...
Bonjour,
on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec
eclipse, on ne peut pas travailler sur le même workspace, comment faire ?
L'installation de cvs est-elle compliquée ?
Merci
"Yannick" a écrit dans le message de news: 4176dfd4$0$4009$
Bonjour, on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec eclipse, on ne peut pas travailler sur le même workspace, comment faire ? L'installation de cvs est-elle compliquée ? Merci
Jaypee
Yannick wrote:
Bonjour, on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec eclipse, on ne peut pas travailler sur le même workspace, comment faire ? L'installation de cvs est-elle compliquée ? Merci
CVS est facile à installer, il faut un serveur dédié, et l'interface
WiewCVS, en lecture seule est très utile pour les "non-développeurs" qui veulent jeter un oeil sur tel ou tel document. Avec le support de ssh et des certificats, il est possible de travailler de manière quasiment transparente, sans taper de mot de passe, tout en gardant un maximum de sécurité par rapport à l'accès aux sources.
Avertissement par rapport à ceux qui ont l'habitude de SourceSafe, voir de CMS, cvs utilise un modèle sans verrouillage des "check out", permettant la modification concurrente des fichiers. Pour certains, c'est impensable, puis à l'usage, on se rend compte que çà marche plutôt bien, avec un minimum de conflit et de blocage administratif.
Je m'éloigne maintenant un petit peu du sujet : Il existe une meilleure solution que cvs. Il s'agit de Subversion <http://subversion.tigris.org>
C'est CVS "en mieux". CVS est très bien -- c'est ce que j'utilise -- mais il est un peu pénible dans la gestion des modifications de dossiers et des fichiers, quand on veut modifier l'organisation des éléments dans un projet en les supprimant ou en les déplaçant.
Subversion permet tout ce que CVS permet et en plus, de versionner un dossier (liste de son contenu), et d'attacher à un fichier des attributs : par exemple, tel script shell reçoit un attribut executable, qui permet de scripter son "check out" en conséquence. Même chose pour les retours de lignes (scripts développés sur Windows, déployés sur Unix)
Les performances subjectives sont meilleures, la liste du "repository" distant est plus rapide qu'avec CVS. Enfin sous Unix, les dossiers de gestion propre à l' outil sont invisibles .svn au lieu du dossier CVS. La migration de CVS vers SVN (subversion) est faite grâce à un script en python qui fait remarquablement son job, en respectant les branches et tout l'historique. la gestion de ssh est encore plus souple. En fait on peut même spécifier un protocole "à soi" autre que ssh.
Seul hic dans ce tableau idyllique, le plugin Eclipse V3.x ne fonctionne pas bien du tout, la commande "check out as project ..." donne un résultat assez inattendu. Et c'est le point principal de blocage à son utilisation avec Eclipse 3.x. Mais la version Eclipse 2.1 fonctionne correctement.
J-P
Yannick wrote:
Bonjour,
on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec
eclipse, on ne peut pas travailler sur le même workspace, comment faire ?
L'installation de cvs est-elle compliquée ?
Merci
CVS est facile à installer, il faut un serveur dédié, et l'interface
WiewCVS, en lecture seule est très utile pour les "non-développeurs"
qui veulent jeter un oeil sur tel ou tel document. Avec le support de
ssh et des certificats, il est possible de travailler de manière
quasiment transparente, sans taper de mot de passe, tout en gardant un
maximum de sécurité par rapport à l'accès aux sources.
Avertissement par rapport à ceux qui ont l'habitude de SourceSafe, voir
de CMS, cvs utilise un modèle sans verrouillage des "check out",
permettant la modification concurrente des fichiers. Pour certains,
c'est impensable, puis à l'usage, on se rend compte que çà marche plutôt
bien, avec un minimum de conflit et de blocage administratif.
Je m'éloigne maintenant un petit peu du sujet : Il existe une meilleure
solution que cvs. Il s'agit de Subversion <http://subversion.tigris.org>
C'est CVS "en mieux". CVS est très bien -- c'est ce que j'utilise --
mais il est un peu pénible dans la gestion des modifications de dossiers
et des fichiers, quand on veut modifier l'organisation des éléments dans
un projet en les supprimant ou en les déplaçant.
Subversion permet tout ce que CVS permet et en plus, de versionner un
dossier (liste de son contenu), et d'attacher à un fichier des
attributs : par exemple, tel script shell reçoit un attribut executable,
qui permet de scripter son "check out" en conséquence. Même chose pour
les retours de lignes (scripts développés sur Windows, déployés sur
Unix)
Les performances subjectives sont meilleures, la liste du "repository"
distant est plus rapide qu'avec CVS. Enfin sous Unix, les dossiers de
gestion propre à l' outil sont invisibles .svn au lieu du dossier CVS.
La migration de CVS vers SVN (subversion) est faite grâce à un script en
python qui fait remarquablement son job, en respectant les branches et
tout l'historique. la gestion de ssh est encore plus souple. En fait on
peut même spécifier un protocole "à soi" autre que ssh.
Seul hic dans ce tableau idyllique, le plugin Eclipse V3.x ne fonctionne
pas bien du tout, la commande "check out as project ..." donne un
résultat assez inattendu. Et c'est le point principal de blocage à son
utilisation avec Eclipse 3.x. Mais la version Eclipse 2.1 fonctionne
correctement.
Bonjour, on utilise eclipse 3.0.1 et on voudrait travailler en équipe. Comme avec eclipse, on ne peut pas travailler sur le même workspace, comment faire ? L'installation de cvs est-elle compliquée ? Merci
CVS est facile à installer, il faut un serveur dédié, et l'interface
WiewCVS, en lecture seule est très utile pour les "non-développeurs" qui veulent jeter un oeil sur tel ou tel document. Avec le support de ssh et des certificats, il est possible de travailler de manière quasiment transparente, sans taper de mot de passe, tout en gardant un maximum de sécurité par rapport à l'accès aux sources.
Avertissement par rapport à ceux qui ont l'habitude de SourceSafe, voir de CMS, cvs utilise un modèle sans verrouillage des "check out", permettant la modification concurrente des fichiers. Pour certains, c'est impensable, puis à l'usage, on se rend compte que çà marche plutôt bien, avec un minimum de conflit et de blocage administratif.
Je m'éloigne maintenant un petit peu du sujet : Il existe une meilleure solution que cvs. Il s'agit de Subversion <http://subversion.tigris.org>
C'est CVS "en mieux". CVS est très bien -- c'est ce que j'utilise -- mais il est un peu pénible dans la gestion des modifications de dossiers et des fichiers, quand on veut modifier l'organisation des éléments dans un projet en les supprimant ou en les déplaçant.
Subversion permet tout ce que CVS permet et en plus, de versionner un dossier (liste de son contenu), et d'attacher à un fichier des attributs : par exemple, tel script shell reçoit un attribut executable, qui permet de scripter son "check out" en conséquence. Même chose pour les retours de lignes (scripts développés sur Windows, déployés sur Unix)
Les performances subjectives sont meilleures, la liste du "repository" distant est plus rapide qu'avec CVS. Enfin sous Unix, les dossiers de gestion propre à l' outil sont invisibles .svn au lieu du dossier CVS. La migration de CVS vers SVN (subversion) est faite grâce à un script en python qui fait remarquablement son job, en respectant les branches et tout l'historique. la gestion de ssh est encore plus souple. En fait on peut même spécifier un protocole "à soi" autre que ssh.
Seul hic dans ce tableau idyllique, le plugin Eclipse V3.x ne fonctionne pas bien du tout, la commande "check out as project ..." donne un résultat assez inattendu. Et c'est le point principal de blocage à son utilisation avec Eclipse 3.x. Mais la version Eclipse 2.1 fonctionne correctement.
J-P
ZebX
...Log du <21/10/2004 00:02> ...Post de <Yannick> :
J'apporte quelques précisions par rapport à mon expérience de tous les jours...
CVS est facile à installer, il faut un serveur dédié, et l'interface non, j'ai CVS sur mon poste de travail, non dédié donc. 4 developpeurs
l'utilisent au quotidien sans aucun pb.
de CMS, cvs utilise un modèle sans verrouillage des "check out", non, il est tout à fait possible de gérer les locks. Ce n'est simplement
pas la config par défaut des clients courants.
-- ZebX - No comprendo
...Log du <21/10/2004 00:02> ...Post de <Yannick>
:
J'apporte quelques précisions par rapport à mon expérience de tous les
jours...
CVS est facile à installer, il faut un serveur dédié, et l'interface
non, j'ai CVS sur mon poste de travail, non dédié donc. 4 developpeurs
l'utilisent au quotidien sans aucun pb.
de CMS, cvs utilise un modèle sans verrouillage des "check out",
non, il est tout à fait possible de gérer les locks. Ce n'est simplement
...Log du <21/10/2004 00:02> ...Post de <Yannick> :
J'apporte quelques précisions par rapport à mon expérience de tous les jours...
CVS est facile à installer, il faut un serveur dédié, et l'interface non, j'ai CVS sur mon poste de travail, non dédié donc. 4 developpeurs
l'utilisent au quotidien sans aucun pb.
de CMS, cvs utilise un modèle sans verrouillage des "check out", non, il est tout à fait possible de gérer les locks. Ce n'est simplement
pas la config par défaut des clients courants.
-- ZebX - No comprendo
Jaypee
ZebX wrote:
...Log du <21/10/2004 00:02> ...Post de <Yannick> :
J'apporte quelques précisions par rapport à mon expérience de tous les jours...
CVS est facile à installer, il faut un serveur dédié, et l'interface non, j'ai CVS sur mon poste de travail, non dédié donc. 4 developpeurs
l'utilisent au quotidien sans aucun pb.
de CMS, cvs utilise un modèle sans verrouillage des "check out", non, il est tout à fait possible de gérer les locks. Ce n'est simplement
pas la config par défaut des clients courants.
Tu as parfaitement raison de dire que c'est possible, mais je ferais la
différence entre ce qui est possible et ce qui est recommandé.
Avec certes un peu de malice, je suppose que ta station ne reboote jamais, qu'elle est blindée physiquement et logiquement, et que les sources qui sont la chose la plus précieuse pour un développeur sont en parfaite sureté et sécurité sur ta station de travail sur laquelle tu débuggues ton code, tu surfes le Web et tu reçois des mails, et où sans doute tu installes toutes les mises à jour de sécurité de l'OS ... etc
Même remarque pour les locks. C'est possible de le faire mais est-ce utile ? Entre donner une fausse impression de sécurité et éduquer les développeurs à comprendre comment CVS fonctionne, je préfère la config par défaut, sans les locks.
Sans ces locks, il y a rarement des situations de blocage, et la résolution des conflits peut se faire à l'amiable.
Avec les locks, on bloque à la moindre difficulté et on escalade à l'administrateur la résolution des conflits.
Laquelle des deux organisations contribue à plus de "zenitude" ?
Mais tes objections restent valides sur le plan technique.
ZebX wrote:
...Log du <21/10/2004 00:02> ...Post de <Yannick>
:
J'apporte quelques précisions par rapport à mon expérience de tous les
jours...
CVS est facile à installer, il faut un serveur dédié, et l'interface
non, j'ai CVS sur mon poste de travail, non dédié donc. 4 developpeurs
l'utilisent au quotidien sans aucun pb.
de CMS, cvs utilise un modèle sans verrouillage des "check out",
non, il est tout à fait possible de gérer les locks. Ce n'est simplement
pas la config par défaut des clients courants.
Tu as parfaitement raison de dire que c'est possible, mais je ferais la
différence entre ce qui est possible et ce qui est recommandé.
Avec certes un peu de malice, je suppose que ta station ne reboote
jamais, qu'elle est blindée physiquement et logiquement, et que les
sources qui sont la chose la plus précieuse pour un développeur sont en
parfaite sureté et sécurité sur ta station de travail sur laquelle tu
débuggues ton code, tu surfes le Web et tu reçois des mails, et où sans
doute tu installes toutes les mises à jour de sécurité de l'OS ... etc
Même remarque pour les locks. C'est possible de le faire mais est-ce
utile ? Entre donner une fausse impression de sécurité et éduquer les
développeurs à comprendre comment CVS fonctionne, je préfère la config
par défaut, sans les locks.
Sans ces locks, il y a rarement des situations de blocage, et la
résolution des conflits peut se faire à l'amiable.
Avec les locks, on bloque à la moindre difficulté et on escalade à
l'administrateur la résolution des conflits.
Laquelle des deux organisations contribue à plus de "zenitude" ?
Mais tes objections restent valides sur le plan technique.
...Log du <21/10/2004 00:02> ...Post de <Yannick> :
J'apporte quelques précisions par rapport à mon expérience de tous les jours...
CVS est facile à installer, il faut un serveur dédié, et l'interface non, j'ai CVS sur mon poste de travail, non dédié donc. 4 developpeurs
l'utilisent au quotidien sans aucun pb.
de CMS, cvs utilise un modèle sans verrouillage des "check out", non, il est tout à fait possible de gérer les locks. Ce n'est simplement
pas la config par défaut des clients courants.
Tu as parfaitement raison de dire que c'est possible, mais je ferais la
différence entre ce qui est possible et ce qui est recommandé.
Avec certes un peu de malice, je suppose que ta station ne reboote jamais, qu'elle est blindée physiquement et logiquement, et que les sources qui sont la chose la plus précieuse pour un développeur sont en parfaite sureté et sécurité sur ta station de travail sur laquelle tu débuggues ton code, tu surfes le Web et tu reçois des mails, et où sans doute tu installes toutes les mises à jour de sécurité de l'OS ... etc
Même remarque pour les locks. C'est possible de le faire mais est-ce utile ? Entre donner une fausse impression de sécurité et éduquer les développeurs à comprendre comment CVS fonctionne, je préfère la config par défaut, sans les locks.
Sans ces locks, il y a rarement des situations de blocage, et la résolution des conflits peut se faire à l'amiable.
Avec les locks, on bloque à la moindre difficulté et on escalade à l'administrateur la résolution des conflits.
Laquelle des deux organisations contribue à plus de "zenitude" ?
Mais tes objections restent valides sur le plan technique.
ZebX
...Log du <21/10/2004 21:27> ...Post de <Jaypee> :
Tu as parfaitement raison de dire que c'est possible, mais je ferais la différence entre ce qui est possible et ce qui est recommandé.
Réponse très pertinente. Je suis 100% d'accord sur ce point et la suite.
Le travail en équipe reste un pb d'organisation avant tout. SVN semble techniquement plus avancé que son illustre ancètre et un peu plus simple d'usage. Mais, ca reste un outil et pas un assistant qui réfléchit à la place des réalisateurs.
Quant a ma config hétéroclite, elle est bien sûr décrite partiellement et a ses raisons (et ses faiblesses ;)).
Mes remarques sur le lock sont bien purement techniques. Perso, je n'y vois aucun intérêt.
-- ZebX - No comprendo
...Log du <21/10/2004 21:27> ...Post de <Jaypee>
:
Tu as parfaitement raison de dire que c'est possible, mais je ferais la
différence entre ce qui est possible et ce qui est recommandé.
Réponse très pertinente.
Je suis 100% d'accord sur ce point et la suite.
Le travail en équipe reste un pb d'organisation avant tout.
SVN semble techniquement plus avancé que son illustre ancètre et un peu
plus simple d'usage. Mais, ca reste un outil et pas un assistant qui
réfléchit à la place des réalisateurs.
Quant a ma config hétéroclite, elle est bien sûr décrite partiellement
et a ses raisons (et ses faiblesses ;)).
Mes remarques sur le lock sont bien purement techniques. Perso, je n'y
vois aucun intérêt.
...Log du <21/10/2004 21:27> ...Post de <Jaypee> :
Tu as parfaitement raison de dire que c'est possible, mais je ferais la différence entre ce qui est possible et ce qui est recommandé.
Réponse très pertinente. Je suis 100% d'accord sur ce point et la suite.
Le travail en équipe reste un pb d'organisation avant tout. SVN semble techniquement plus avancé que son illustre ancètre et un peu plus simple d'usage. Mais, ca reste un outil et pas un assistant qui réfléchit à la place des réalisateurs.
Quant a ma config hétéroclite, elle est bien sûr décrite partiellement et a ses raisons (et ses faiblesses ;)).
Mes remarques sur le lock sont bien purement techniques. Perso, je n'y vois aucun intérêt.
