CVSROOT et Tomcat

guillaume.outters

08/12/2003 à 21:57

Yvon Thoraval wrote:

je suis le user guide de tomcat à fin de compiler un servlet.

à l'étape :

cvs import -m "Initial Project Creation" SalutTotoServlet toto start

cvs m'a répondu :

cvs import: No CVSROOT specified! Please use the `-d' option
cvs [import aborted]: or set the CVSROOT environment variable.

donc j'ai essayé les DEUX ie. -d {dir} et export CVSROOT={dir}

bon je vérifie que l'export a bien marché.

mais après un nouvel import j'ai tjs :

cvs [import aborted]:
/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet/CVSROOT: No such
file or directory

qu'est-ce que j'ai raté ???

CVS n'est pas une étape obligatoire du process. CVS est un outil de
versionnage, c'est-à-dire qu'il t'aide à créer un historique des
versions de ton servlet. En gros, lorsque tu démarres ton projet, tu
construis ton servlet, dès que tu as quelque chose de stable hop tu
demandes à CVS d'enregistrer l'état de tes sources. Ensuite tu continues
à bosser sur ton truc, et si tu casses accidentellement quelque chose tu
peux toujours revenir à la dernière version qui fonctionnait. Dès que tu
as une nouvelle version stable tu enregistres, etc. À chaque fois que tu
enregistres sous CVS, on dit que tu "versionnes", car CVS attribue (en
interne) un nouveau numéro de version à tes sources.

Ça te donne donc, au lieu de ta seule arborescence de code source, deux
arborescences: ton arbo, sur laquelle tu travailles, et l'arbo CVS, qui
préserve de tes exactions une version stable (errare humanum est,
surtout sous Unix).

Ça, c'est pour l'usage "utilisateur seul". En réalité, CVS sert surtout,
dans le cadre d'un développement multi-utilisateurs, à avoir une base
commune et stable dont chacun possède une copie sur laquelle il peut
faire ses bidouilles, tests et débogage, et lorsqu'il possède une
version stable du module qu'il développe il l'envoie dans le
"repository" CVS pour que les autres puissent le télécharger.

L'autre utilité de CVS (et la raison pour laquelle je l'utilise même
quand je bosse seul) est qu'à chaque version tu peux associer un
commentaire. Ça te permet ensuite, lors des longues soirées d'hiver où
tu es en manque d'auto-satisfaction, de lui demander de resortir
l'ensemble des commentaires et de resuivre, les yeux embués par
l'émotion, l'histoire de ton projet, les ajouts, les corrections de
bogues, etc.

Autre motivation: pouvoir bosser sur plusieurs machines (boulot, perso);
CVS étant un minimum intelligent, il te permettra de résoudre quelques
conflits du genre:
CVS possède la version d'un source qui contient ABC, tu as synchronisé
ta machine de bureau et ton portable dessus. Le soir tu as fait des
ajouts sur la machine de bureau (qui ont résulté en un fichier constitué
de AdBC), mais tu avais sommeil et tu es parti sans envoyer l'ajout à
CVS (ou alors ça ne compilait pas et tu préfères que la version connue
de CVS soit toujours la dernière version redéployable immédiatement, ce
en quoi tu auras raison). Le lendemain matin, tu es parti avec ton
portable avec sa version contenant ABC, en journée tu as fait des ajouts
(ABCe). Le soir tu reviens, tu finis ton boulot sur la machine de bureau
(AdfBC), et tu décides de tout envoyer sous CVS (parce que les parties
df et e sont stables). Et là, magie de CVS, tu obtiens AdfBCe!

Encore un avantage: tu peux demander à CVS un diff entre plusieurs
versions de ton source, et entre autres entre la dernière version
stockée sous CVS et ta copie de travail. Comme ça tu peux voir
rapidement toutes les modifs que tu as faites depuis ta dernière version
stable.

Bon, sinon, pour la mise en route rapide: <http://www.cvshome.org>.

Pour la mise en route encore plus rapide, en configuration "utilisateur
seul":
# On indique à CVS que toutes les commandes qui suivent bosseront sur le
# "repository" situé dans ~/Library/Application Support/cvs (il y
# stocke les sources et les commentaires associés):
export CVSROOT=~/Library/Application Support/cvs
# Qu'il y crée son bazar interne!
cvs init
# Puis le cvs import et la suite

Avoir défini un CVSROOT t'évite d'avoir à taper à chaque fois
cvs -d $CVSROOT
Quand il te disait qu'il ne trouvait pas de CVSROOT, c'est qu'en fait il
ne savait pas où stocker les versions que tu lui soumettais.

Bon, si mes explications te semblent un peu pas claires ou longues,
n'hésite pas à me demander des précisions sur certains points, je
commence à connaître le sujet!

--
Guillaume

Yvon Thoraval <yvon.thoravalNO@SPAMfree.fr> wrote:

je suis le user guide de tomcat à fin de compiler un servlet.

à l'étape :

cvs import -m "Initial Project Creation" SalutTotoServlet toto start

cvs m'a répondu :

cvs import: No CVSROOT specified! Please use the `-d' option
cvs [import aborted]: or set the CVSROOT environment variable.

donc j'ai essayé les DEUX ie. -d {dir} et export CVSROOT={dir}

bon je vérifie que l'export a bien marché.

mais après un nouvel import j'ai tjs :

cvs [import aborted]:
/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet/CVSROOT: No such
file or directory

qu'est-ce que j'ai raté ???

CVS n'est pas une étape obligatoire du process. CVS est un outil de
versionnage, c'est-à-dire qu'il t'aide à créer un historique des
versions de ton servlet. En gros, lorsque tu démarres ton projet, tu
construis ton servlet, dès que tu as quelque chose de stable hop tu
demandes à CVS d'enregistrer l'état de tes sources. Ensuite tu continues
à bosser sur ton truc, et si tu casses accidentellement quelque chose tu
peux toujours revenir à la dernière version qui fonctionnait. Dès que tu
as une nouvelle version stable tu enregistres, etc. À chaque fois que tu
enregistres sous CVS, on dit que tu "versionnes", car CVS attribue (en
interne) un nouveau numéro de version à tes sources.

Ça te donne donc, au lieu de ta seule arborescence de code source, deux
arborescences: ton arbo, sur laquelle tu travailles, et l'arbo CVS, qui
préserve de tes exactions une version stable (errare humanum est,
surtout sous Unix).

Ça, c'est pour l'usage "utilisateur seul". En réalité, CVS sert surtout,
dans le cadre d'un développement multi-utilisateurs, à avoir une base
commune et stable dont chacun possède une copie sur laquelle il peut
faire ses bidouilles, tests et débogage, et lorsqu'il possède une
version stable du module qu'il développe il l'envoie dans le
"repository" CVS pour que les autres puissent le télécharger.

L'autre utilité de CVS (et la raison pour laquelle je l'utilise même
quand je bosse seul) est qu'à chaque version tu peux associer un
commentaire. Ça te permet ensuite, lors des longues soirées d'hiver où
tu es en manque d'auto-satisfaction, de lui demander de resortir
l'ensemble des commentaires et de resuivre, les yeux embués par
l'émotion, l'histoire de ton projet, les ajouts, les corrections de
bogues, etc.

Autre motivation: pouvoir bosser sur plusieurs machines (boulot, perso);
CVS étant un minimum intelligent, il te permettra de résoudre quelques
conflits du genre:
CVS possède la version d'un source qui contient ABC, tu as synchronisé
ta machine de bureau et ton portable dessus. Le soir tu as fait des
ajouts sur la machine de bureau (qui ont résulté en un fichier constitué
de AdBC), mais tu avais sommeil et tu es parti sans envoyer l'ajout à
CVS (ou alors ça ne compilait pas et tu préfères que la version connue
de CVS soit toujours la dernière version redéployable immédiatement, ce
en quoi tu auras raison). Le lendemain matin, tu es parti avec ton
portable avec sa version contenant ABC, en journée tu as fait des ajouts
(ABCe). Le soir tu reviens, tu finis ton boulot sur la machine de bureau
(AdfBC), et tu décides de tout envoyer sous CVS (parce que les parties
df et e sont stables). Et là, magie de CVS, tu obtiens AdfBCe!

Encore un avantage: tu peux demander à CVS un diff entre plusieurs
versions de ton source, et entre autres entre la dernière version
stockée sous CVS et ta copie de travail. Comme ça tu peux voir
rapidement toutes les modifs que tu as faites depuis ta dernière version
stable.

Bon, sinon, pour la mise en route rapide: <http://www.cvshome.org>.

Pour la mise en route encore plus rapide, en configuration "utilisateur
seul":
# On indique à CVS que toutes les commandes qui suivent bosseront sur le
# "repository" situé dans ~/Library/Application Support/cvs (il y
# stocke les sources et les commentaires associés):
export CVSROOT=~/Library/Application Support/cvs
# Qu'il y crée son bazar interne!
cvs init
# Puis le cvs import et la suite

Avoir défini un CVSROOT t'évite d'avoir à taper à chaque fois
cvs -d $CVSROOT
Quand il te disait qu'il ne trouvait pas de CVSROOT, c'est qu'en fait il
ne savait pas où stocker les versions que tu lui soumettais.

Bon, si mes explications te semblent un peu pas claires ou longues,
n'hésite pas à me demander des précisions sur certains points, je
commence à connaître le sujet!

--
Guillaume

Vous avez filtré cet utilisateur ! Consultez son message

Yvon Thoraval wrote:

je suis le user guide de tomcat à fin de compiler un servlet.

à l'étape :

cvs import -m "Initial Project Creation" SalutTotoServlet toto start

cvs m'a répondu :

cvs import: No CVSROOT specified! Please use the `-d' option
cvs [import aborted]: or set the CVSROOT environment variable.

donc j'ai essayé les DEUX ie. -d {dir} et export CVSROOT={dir}

bon je vérifie que l'export a bien marché.

mais après un nouvel import j'ai tjs :

cvs [import aborted]:
/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet/CVSROOT: No such
file or directory

qu'est-ce que j'ai raté ???

CVS n'est pas une étape obligatoire du process. CVS est un outil de
versionnage, c'est-à-dire qu'il t'aide à créer un historique des
versions de ton servlet. En gros, lorsque tu démarres ton projet, tu
construis ton servlet, dès que tu as quelque chose de stable hop tu
demandes à CVS d'enregistrer l'état de tes sources. Ensuite tu continues
à bosser sur ton truc, et si tu casses accidentellement quelque chose tu
peux toujours revenir à la dernière version qui fonctionnait. Dès que tu
as une nouvelle version stable tu enregistres, etc. À chaque fois que tu
enregistres sous CVS, on dit que tu "versionnes", car CVS attribue (en
interne) un nouveau numéro de version à tes sources.

Ça te donne donc, au lieu de ta seule arborescence de code source, deux
arborescences: ton arbo, sur laquelle tu travailles, et l'arbo CVS, qui
préserve de tes exactions une version stable (errare humanum est,
surtout sous Unix).

Ça, c'est pour l'usage "utilisateur seul". En réalité, CVS sert surtout,
dans le cadre d'un développement multi-utilisateurs, à avoir une base
commune et stable dont chacun possède une copie sur laquelle il peut
faire ses bidouilles, tests et débogage, et lorsqu'il possède une
version stable du module qu'il développe il l'envoie dans le
"repository" CVS pour que les autres puissent le télécharger.

L'autre utilité de CVS (et la raison pour laquelle je l'utilise même
quand je bosse seul) est qu'à chaque version tu peux associer un
commentaire. Ça te permet ensuite, lors des longues soirées d'hiver où
tu es en manque d'auto-satisfaction, de lui demander de resortir
l'ensemble des commentaires et de resuivre, les yeux embués par
l'émotion, l'histoire de ton projet, les ajouts, les corrections de
bogues, etc.

Autre motivation: pouvoir bosser sur plusieurs machines (boulot, perso);
CVS étant un minimum intelligent, il te permettra de résoudre quelques
conflits du genre:
CVS possède la version d'un source qui contient ABC, tu as synchronisé
ta machine de bureau et ton portable dessus. Le soir tu as fait des
ajouts sur la machine de bureau (qui ont résulté en un fichier constitué
de AdBC), mais tu avais sommeil et tu es parti sans envoyer l'ajout à
CVS (ou alors ça ne compilait pas et tu préfères que la version connue
de CVS soit toujours la dernière version redéployable immédiatement, ce
en quoi tu auras raison). Le lendemain matin, tu es parti avec ton
portable avec sa version contenant ABC, en journée tu as fait des ajouts
(ABCe). Le soir tu reviens, tu finis ton boulot sur la machine de bureau
(AdfBC), et tu décides de tout envoyer sous CVS (parce que les parties
df et e sont stables). Et là, magie de CVS, tu obtiens AdfBCe!

Encore un avantage: tu peux demander à CVS un diff entre plusieurs
versions de ton source, et entre autres entre la dernière version
stockée sous CVS et ta copie de travail. Comme ça tu peux voir
rapidement toutes les modifs que tu as faites depuis ta dernière version
stable.

Bon, sinon, pour la mise en route rapide: <http://www.cvshome.org>.

Pour la mise en route encore plus rapide, en configuration "utilisateur
seul":
# On indique à CVS que toutes les commandes qui suivent bosseront sur le
# "repository" situé dans ~/Library/Application Support/cvs (il y
# stocke les sources et les commentaires associés):
export CVSROOT=~/Library/Application Support/cvs
# Qu'il y crée son bazar interne!
cvs init
# Puis le cvs import et la suite

Avoir défini un CVSROOT t'évite d'avoir à taper à chaque fois
cvs -d $CVSROOT
Quand il te disait qu'il ne trouvait pas de CVSROOT, c'est qu'en fait il
ne savait pas où stocker les versions que tu lui soumettais.

Bon, si mes explications te semblent un peu pas claires ou longues,
n'hésite pas à me demander des précisions sur certains points, je
commence à connaître le sujet!

--
Guillaume

yvon.thoravalNO

09/12/2003 à 01:30

Guillaume Outters wrote:

Avoir défini un CVSROOT t'évite d'avoir à taper à chaque fois cvs -d
$CVSROOT Quand il te disait qu'il ne trouvait pas de CVSROOT, c'est qu'en
fait il ne savait pas où stocker les versions que tu lui soumettais.

oui, merci pour ta réponse si longue !

en fait mon pb était particulièrement simple (ce qui n'est pas indiqué
dans le tuto Tomcat qui suppose que c'est déjà fait, par ailleurs...) :

il faut commencer par un cvs init....

Bon, si mes explications te semblent un peu pas claires ou longues,
n'hésite pas à me demander des précisions sur certains points, je commence
à connaître le sujet!

j'avoue avoir laissé un peu tomber cvs, question d'urgence, mais par
exemple je m'étais trompé d'endroit où mettre build.xml, donc j'ai juste
changé de place de ce fichier dans mon répertoire de travail, et là je
ne pige pas quelle est la commande pour dire à cvs de "rafraichir" le
repository...

MON VÉRITABLE PB MAINTENANT EST AVEC ANT...

ant compile bien mais me donne une erreur à l'install :

yvonthor$ ant install Buildfile: build.xml

prepare:

compile:

install:

BUILD FAILED
/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet/build.xml:364:
java.io.IOException: Server returned HTTP response code: 401 for URL:
http://localhost:8080/manager/install?path=%2FLibrary%2FTomcat%2Fwebapps%2
FROOT%2FSERVLETS%2FSalutTotoServlet&war=file%3A%2F%2F%2FLibrary%2FTomcat%2
Fwebapps%2FROOT%2FSERVLETS%2FSalutTotoServlet%2Fbuild

je ne pige pas pourquoi ant utilise l'URL :

http://localhost:8080/manager/install?path=% ...

vu qu'il n'y a pas de répertoire manager dans celui de Tomcat.

je pense que mon fihier "build.properties" est incorrect :

# Context path to install this application on
app.path=/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet

# Tomcat 4 installation directory catalina.home=/Library/Tomcat

# Manager webapp username and password
manager.username=yvonthor manager.password=mypwd

-- Yvon Thoraval

Guillaume Outters <guillaume.outters@free.fr> wrote:

Avoir défini un CVSROOT t'évite d'avoir à taper à chaque fois cvs -d
$CVSROOT Quand il te disait qu'il ne trouvait pas de CVSROOT, c'est qu'en
fait il ne savait pas où stocker les versions que tu lui soumettais.

oui, merci pour ta réponse si longue !

en fait mon pb était particulièrement simple (ce qui n'est pas indiqué
dans le tuto Tomcat qui suppose que c'est déjà fait, par ailleurs...) :

il faut commencer par un cvs init....

Bon, si mes explications te semblent un peu pas claires ou longues,
n'hésite pas à me demander des précisions sur certains points, je commence
à connaître le sujet!

j'avoue avoir laissé un peu tomber cvs, question d'urgence, mais par
exemple je m'étais trompé d'endroit où mettre build.xml, donc j'ai juste
changé de place de ce fichier dans mon répertoire de travail, et là je
ne pige pas quelle est la commande pour dire à cvs de "rafraichir" le
repository...

MON VÉRITABLE PB MAINTENANT EST AVEC ANT...

ant compile bien mais me donne une erreur à l'install :

yvonthor$ ant install Buildfile: build.xml

prepare:

compile:

install:

BUILD FAILED
/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet/build.xml:364:
java.io.IOException: Server returned HTTP response code: 401 for URL:
http://localhost:8080/manager/install?path=%2FLibrary%2FTomcat%2Fwebapps%2
FROOT%2FSERVLETS%2FSalutTotoServlet&war=file%3A%2F%2F%2FLibrary%2FTomcat%2
Fwebapps%2FROOT%2FSERVLETS%2FSalutTotoServlet%2Fbuild

je ne pige pas pourquoi ant utilise l'URL :

http://localhost:8080/manager/install?path=% ...

vu qu'il n'y a pas de répertoire manager dans celui de Tomcat.

je pense que mon fihier "build.properties" est incorrect :

# Context path to install this application on
app.path=/Library/Tomcat/webapps/ROOT/SERVLETS/SalutTotoServlet

# Tomcat 4 installation directory catalina.home=/Library/Tomcat

# Manager webapp username and password
manager.username=yvonthor manager.password=mypwd

-- Yvon Thoraval

Vous avez filtré cet utilisateur ! Consultez son message

guillaume.outters

09/12/2003 à 07:43

Yvon Thoraval wrote:

j'avoue avoir laissé un peu tomber cvs, question d'urgence, mais par
exemple je m'étais trompé d'endroit où mettre build.xml, donc j'ai juste
changé de place de ce fichier dans mon répertoire de travail, et là je
ne pige pas quelle est la commande pour dire à cvs de "rafraichir" le
repository...

Ça, c'est le problème de CVS, et c'est pourquoi on a une nouvelle
génération d'outils de versionnage qui savent tracer les déplacements de
fichiers ou dossiers. Sous CVS, deux solutions tout aussi bancale l'une
que l'autre:

- Crade: tu commit toutes tes modifs puis tu vas à la racine du
repository CVS et tu déplace le fichier build.xml,v au bon endroit.
Ensuite tu effaces ton fichier local et tu fais un update. C'est
dangereux en multi-utilisateurs (il faut que tout le monde soit prévenu
en même temps).

- Débile mais c'est à cause de CVS: tu fais un cvs remove de l'ancienne
position, un cvs add à la nouvelle. C'est le plus "propre", puisque tu
restes du côté utilisateur de CVS sans trifouiller le repository, mais
tu perds l'historique du fichier sous CVS.
Sur un projet sur lequel on bosse, j'ai institué un format strict de
commentaires: chaque modif doit commencer par un "tiret", suivi du
commentaire. Les tirets sont les suivants:
+ ajout de fonctionnalité
= correction, utilisation d'un autre algo
- suppression de code (redondant, obsolète)
# déplacement de fichier
Dans ce cas, je mets:
# truc/build.xml > src/build.xml
Afin que, au moins manuellement, on puisse suivre l'évolution du fichier
en retrouvant les logs à son ancien emplacement (un cvs remove déplace
en fait le fichier dans le repository dans un sous-répertoire Attic, il
garde donc le fichier mais simplement il n'apparaît plus quand tu fais
un cvs update).

MON VÉRITABLE PB MAINTENANT EST AVEC ANT...

Bon, ça je ne sais pas faire. Je change le sujet du fil, et puis ceux
qui veulent (et peuvent aussi, ce serait bien) t'aider iront consulter
ton message précédent.

--
Guillaume

Yvon Thoraval <yvon.thoravalNO@SPAMfree.fr> wrote:

j'avoue avoir laissé un peu tomber cvs, question d'urgence, mais par
exemple je m'étais trompé d'endroit où mettre build.xml, donc j'ai juste
changé de place de ce fichier dans mon répertoire de travail, et là je
ne pige pas quelle est la commande pour dire à cvs de "rafraichir" le
repository...

Ça, c'est le problème de CVS, et c'est pourquoi on a une nouvelle
génération d'outils de versionnage qui savent tracer les déplacements de
fichiers ou dossiers. Sous CVS, deux solutions tout aussi bancale l'une
que l'autre:

- Crade: tu commit toutes tes modifs puis tu vas à la racine du
repository CVS et tu déplace le fichier build.xml,v au bon endroit.
Ensuite tu effaces ton fichier local et tu fais un update. C'est
dangereux en multi-utilisateurs (il faut que tout le monde soit prévenu
en même temps).

- Débile mais c'est à cause de CVS: tu fais un cvs remove de l'ancienne
position, un cvs add à la nouvelle. C'est le plus "propre", puisque tu
restes du côté utilisateur de CVS sans trifouiller le repository, mais
tu perds l'historique du fichier sous CVS.
Sur un projet sur lequel on bosse, j'ai institué un format strict de
commentaires: chaque modif doit commencer par un "tiret", suivi du
commentaire. Les tirets sont les suivants:
+ ajout de fonctionnalité
= correction, utilisation d'un autre algo
- suppression de code (redondant, obsolète)
# déplacement de fichier
Dans ce cas, je mets:
# truc/build.xml > src/build.xml
Afin que, au moins manuellement, on puisse suivre l'évolution du fichier
en retrouvant les logs à son ancien emplacement (un cvs remove déplace
en fait le fichier dans le repository dans un sous-répertoire Attic, il
garde donc le fichier mais simplement il n'apparaît plus quand tu fais
un cvs update).

MON VÉRITABLE PB MAINTENANT EST AVEC ANT...

Bon, ça je ne sais pas faire. Je change le sujet du fil, et puis ceux
qui veulent (et peuvent aussi, ce serait bien) t'aider iront consulter
ton message précédent.

--
Guillaume

Vous avez filtré cet utilisateur ! Consultez son message

yvon.thoravalNO

09/12/2003 à 08:24

Guillaume Outters wrote:

Ça, c'est le problème de CVS, et c'est pourquoi on a une nouvelle
génération d'outils de versionnage qui savent tracer les déplacements de
fichiers ou dossiers. Sous CVS, deux solutions tout aussi bancale l'une
que l'autre:
[quick]

bon j'avais choisi la méthode propre mais "débile"...

MON VÉRITABLE PB MAINTENANT EST AVEC ANT...

Bon, ça je ne sais pas faire. Je change le sujet du fil, et puis ceux
qui veulent (et peuvent aussi, ce serait bien) t'aider iront consulter
ton message précédent.

ok, je vais faire un autre fil
--
Yvon Thoraval

yvon.thoravalNO

09/12/2003 à 09:25

Guillaume Outters wrote:

- Débile mais c'est à cause de CVS: tu fais un cvs remove de l'ancienne
position, un cvs add à la nouvelle. C'est le plus "propre", puisque tu
restes du côté utilisateur de CVS sans trifouiller le repository, mais
tu perds l'historique du fichier sous CVS.

bon j'ai fait :
SalutTotoServlet/src yvonthor$ cvs remove -f build.xml
cvs remove: cannot open CVS/Entries for reading: No such file or
directory
cvs remove: nothing known about `build.xml'

là build.xml et retiré du répertoire de travail, MAIS PAS du répository
où j'ai tjs : build.xml,v

je change de rep pour faire :
SalutTotoServlet yvonthor$ cvs add -m "Ajout build.xml" build.xml
cvs add: in directory .:
cvs [add aborted]: there is no version here; do 'cvs checkout' first

si je fais un checkout, ça déconne aussi, j'ai l'impression d'avoir tout
embrouillé ???

je sorts du rep, et je fais :

yvonthor$ cvs checkout SalutTotoServlet
cvs checkout: Updating SalutTotoServlet
U SalutTotoServlet/.cvsignore
? SalutTotoServlet/build.xml
? SalutTotoServlet/docs
? SalutTotoServlet/src
? SalutTotoServlet/web

ca me donne un nouveau rep CVS dans mon rep "SalutTotoServlet" avec les
fichiers :

Entries
Repository
Root

(j'ai enlevé, à la main, le précédent src/build.xml,v)

puis je fais cvs commit

et là je suis dans (vi je suppose)

puis je sorts par :

"/private/tmp/cvsTtbGGp" [crypted] 10L, 308C written
RCS file: /Users/yvonthor/Sites/CVS/SalutTotoServlet/build.xml,v
done
Checking in build.xml;
/Users/yvonthor/Sites/CVS/SalutTotoServlet/build.xml,v <-- build.xml
initial revision: 1.1
done

à ton avis enlever, à la main le src/build.xml,v
c'est correct ?
j'ai ajouté /build.xml,v après coup...
--
Yvon Thoraval

guillaume.outters

09/12/2003 à 22:22

Yvon Thoraval wrote:

bon j'ai fait :
SalutTotoServlet/src yvonthor$ cvs remove -f build.xml
cvs remove: cannot open CVS/Entries for reading: No such file or
directory
cvs remove: nothing known about `build.xml'

Par hasard, SalutTotoServlet/src ne serait-il pas le répertoire dans
lequel tu as fait un "import"? L'import ne lie pas tes sources à CVS, il
ne fait que les y copier. Ensuite si tu veux avoir un répertoire
synchronisé sur CVS, il faut faire un checkout (co en abrégé). D'où dans
le tutoriel (c'est bien <
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/appdev/processes.html>
que tu lis?) le paragraphe:
cd ..
mv myapp myapp.bu
cvs checkout {project}
Le répertoire duquel tu pars (myapp dans leur cas) est celui qui a été
importé (copié, donc). Ici, ils le mettent de côté (myapp.bu) et
recréent un myapp à partir de CVS. Si le répertoire a été bien importé,
la seule différence (diff -r myapp.bu myapp) doit être l'apparition de
répertoires CVS dans myapp.
Pour qu'un de tes répertoires sources soit miroir d'un chais CVS
(j'utilise "chais" à partir de maintenant, c'est plus court que
repository et ça exprime plus ou moins l'idée de stockage central et
j'aime bien franciser tout ce qui me tombe sous la main), il faut qu'il
contienne un sous-répertoire CVS. Dedans tu trouveras un fichier Root,
qui donne le chemin du chais (et qui t'évite de retaper le "-d" de "cvs
-d ..." à chaque nouvelle commande dans ton répertoire versionné), un
fichier Repository qui donne le chemin dans le chais et un Entries
indiquant ceux qui sont versionnés.

là build.xml et retiré du répertoire de travail, MAIS PAS du répository
où j'ai tjs : build.xml,v

Ouais, donc il aurait effectué le "-f" du "remove -f" avant de voir s'il
connaissait CVS.

si je fais un checkout, ça déconne aussi, j'ai l'impression d'avoir tout
embrouillé ???

Quand tu importes un répertoire Projet, l'import est à faire dans
Projet, tandis que le checkout doit être fait dans le répertoire qui
contiendra Projet (bon, là c'est un peu normal puisque Projet n'existe
pas encore). Attention à la différence de fonctionnement (je me plante
approximativement une fois sur une). Là, si tu est remonté dans
SalutTotoServlet, il a dû te créer un sous-répertoire de
SalutTotoServlet nommé SalutTotoServlet.

Généralement, quand je veux importer sous CVS, je fais (et ce qu'ils
font aussi dans leur manuel):
cd ProjetDeLaMortQuiTue
cvs -d ... import -m "Gnagna" ProjetDeLaMortQuiTue guigui principal
cd ..
mv ProjetDeLaMortQuiTue ProjetDeLaMortQuiTue.2
cvs -d ... co ProjetDeLaMortQuiTue
diff -r ProjetDeLaMortQuiTue*

je sorts du rep, et je fais :

yvonthor$ cvs checkout SalutTotoServlet
cvs checkout: Updating SalutTotoServlet
U SalutTotoServlet/.cvsignore
? SalutTotoServlet/build.xml
? SalutTotoServlet/docs
? SalutTotoServlet/src
? SalutTotoServlet/web

Donc là c'est tout bon au détail près que tu as oublié de renommer le
répertoire entretemps. Donc, euh, que fait-il au juste? Mettons qu'il
voudrait bien resortir le 'src' qu'il connaît en chais CVS mais tombe
sur ton répertoire existant et est un peu gêné car ton répertoire ne
contient pas de sous-répertoire CVS (là c'est de la pure conjecture ce
que je raconte).

ca me donne un nouveau rep CVS dans mon rep "SalutTotoServlet" avec les
fichiers :

Entries
Repository
Root

(j'ai enlevé, à la main, le précédent src/build.xml,v)

Est-ce qu'il t'a créé des répertoires CVS de la même facture dans src,
docs et web? Si non, les "?" du checkout étaient mauvais signe, et il
vaut mieux reprendre proprement (mv SalutTotoServlet SalutTotoServlet.2
et cvs co SalutTotoServlet, avec un diff -r pour te faire une idée de
l'état de l'autre)

puis je fais cvs commit

et là je suis dans (vi je suppose)

Oui, si tu ne donnes pas le commentaire par l'option "-m" de cvs, il te
demande de le rentrer sous ton éditeur par défaut qui a de grandes
chances d'être vi.

à ton avis enlever, à la main le src/build.xml,v
c'est correct ?
j'ai ajouté /build.xml,v après coup...

Oui, fais-le, mais à éviter quand même un minimum une fois que le projet
sera en route, pour préserver les log. Là comme le log ne devait
contenir que "Initial import", ça ne sera pas une perte pleurée par
beaucoup.

P.S.: si tu souhaites des temps de réponse un peu plus faibles, tu peux
toujours poursuivre par courriel, mon adresse est tout ce qu'il y a de
plus en clair. Au boulot, on n'a pas usenet, mais on peut tout de même
consulter son courrier.

--
Guillaume

Yvon Thoraval <yvon.thoravalNO@SPAMfree.fr> wrote:

bon j'ai fait :
SalutTotoServlet/src yvonthor$ cvs remove -f build.xml
cvs remove: cannot open CVS/Entries for reading: No such file or
directory
cvs remove: nothing known about `build.xml'

Par hasard, SalutTotoServlet/src ne serait-il pas le répertoire dans
lequel tu as fait un "import"? L'import ne lie pas tes sources à CVS, il
ne fait que les y copier. Ensuite si tu veux avoir un répertoire
synchronisé sur CVS, il faut faire un checkout (co en abrégé). D'où dans
le tutoriel (c'est bien <
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/appdev/processes.html>
que tu lis?) le paragraphe:
cd ..
mv myapp myapp.bu
cvs checkout {project}
Le répertoire duquel tu pars (myapp dans leur cas) est celui qui a été
importé (copié, donc). Ici, ils le mettent de côté (myapp.bu) et
recréent un myapp à partir de CVS. Si le répertoire a été bien importé,
la seule différence (diff -r myapp.bu myapp) doit être l'apparition de
répertoires CVS dans myapp.
Pour qu'un de tes répertoires sources soit miroir d'un chais CVS
(j'utilise "chais" à partir de maintenant, c'est plus court que
repository et ça exprime plus ou moins l'idée de stockage central et
j'aime bien franciser tout ce qui me tombe sous la main), il faut qu'il
contienne un sous-répertoire CVS. Dedans tu trouveras un fichier Root,
qui donne le chemin du chais (et qui t'évite de retaper le "-d" de "cvs
-d ..." à chaque nouvelle commande dans ton répertoire versionné), un
fichier Repository qui donne le chemin dans le chais et un Entries
indiquant ceux qui sont versionnés.

là build.xml et retiré du répertoire de travail, MAIS PAS du répository
où j'ai tjs : build.xml,v

Ouais, donc il aurait effectué le "-f" du "remove -f" avant de voir s'il
connaissait CVS.

si je fais un checkout, ça déconne aussi, j'ai l'impression d'avoir tout
embrouillé ???

Quand tu importes un répertoire Projet, l'import est à faire dans
Projet, tandis que le checkout doit être fait dans le répertoire qui
contiendra Projet (bon, là c'est un peu normal puisque Projet n'existe
pas encore). Attention à la différence de fonctionnement (je me plante
approximativement une fois sur une). Là, si tu est remonté dans
SalutTotoServlet, il a dû te créer un sous-répertoire de
SalutTotoServlet nommé SalutTotoServlet.

Généralement, quand je veux importer sous CVS, je fais (et ce qu'ils
font aussi dans leur manuel):
cd ProjetDeLaMortQuiTue
cvs -d ... import -m "Gnagna" ProjetDeLaMortQuiTue guigui principal
cd ..
mv ProjetDeLaMortQuiTue ProjetDeLaMortQuiTue.2
cvs -d ... co ProjetDeLaMortQuiTue
diff -r ProjetDeLaMortQuiTue*

je sorts du rep, et je fais :

yvonthor$ cvs checkout SalutTotoServlet
cvs checkout: Updating SalutTotoServlet
U SalutTotoServlet/.cvsignore
? SalutTotoServlet/build.xml
? SalutTotoServlet/docs
? SalutTotoServlet/src
? SalutTotoServlet/web

Donc là c'est tout bon au détail près que tu as oublié de renommer le
répertoire entretemps. Donc, euh, que fait-il au juste? Mettons qu'il
voudrait bien resortir le 'src' qu'il connaît en chais CVS mais tombe
sur ton répertoire existant et est un peu gêné car ton répertoire ne
contient pas de sous-répertoire CVS (là c'est de la pure conjecture ce
que je raconte).

ca me donne un nouveau rep CVS dans mon rep "SalutTotoServlet" avec les
fichiers :

Entries
Repository
Root

(j'ai enlevé, à la main, le précédent src/build.xml,v)

Est-ce qu'il t'a créé des répertoires CVS de la même facture dans src,
docs et web? Si non, les "?" du checkout étaient mauvais signe, et il
vaut mieux reprendre proprement (mv SalutTotoServlet SalutTotoServlet.2
et cvs co SalutTotoServlet, avec un diff -r pour te faire une idée de
l'état de l'autre)

puis je fais cvs commit

et là je suis dans (vi je suppose)

Oui, si tu ne donnes pas le commentaire par l'option "-m" de cvs, il te
demande de le rentrer sous ton éditeur par défaut qui a de grandes
chances d'être vi.

à ton avis enlever, à la main le src/build.xml,v
c'est correct ?
j'ai ajouté /build.xml,v après coup...

Oui, fais-le, mais à éviter quand même un minimum une fois que le projet
sera en route, pour préserver les log. Là comme le log ne devait
contenir que "Initial import", ça ne sera pas une perte pleurée par
beaucoup.

P.S.: si tu souhaites des temps de réponse un peu plus faibles, tu peux
toujours poursuivre par courriel, mon adresse est tout ce qu'il y a de
plus en clair. Au boulot, on n'a pas usenet, mais on peut tout de même
consulter son courrier.

--
Guillaume

Vous avez filtré cet utilisateur ! Consultez son message

Yvon Thoraval wrote:

bon j'ai fait :
SalutTotoServlet/src yvonthor$ cvs remove -f build.xml
cvs remove: cannot open CVS/Entries for reading: No such file or
directory
cvs remove: nothing known about `build.xml'

Par hasard, SalutTotoServlet/src ne serait-il pas le répertoire dans
lequel tu as fait un "import"? L'import ne lie pas tes sources à CVS, il
ne fait que les y copier. Ensuite si tu veux avoir un répertoire
synchronisé sur CVS, il faut faire un checkout (co en abrégé). D'où dans
le tutoriel (c'est bien <
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/appdev/processes.html>
que tu lis?) le paragraphe:
cd ..
mv myapp myapp.bu
cvs checkout {project}
Le répertoire duquel tu pars (myapp dans leur cas) est celui qui a été
importé (copié, donc). Ici, ils le mettent de côté (myapp.bu) et
recréent un myapp à partir de CVS. Si le répertoire a été bien importé,
la seule différence (diff -r myapp.bu myapp) doit être l'apparition de
répertoires CVS dans myapp.
Pour qu'un de tes répertoires sources soit miroir d'un chais CVS
(j'utilise "chais" à partir de maintenant, c'est plus court que
repository et ça exprime plus ou moins l'idée de stockage central et
j'aime bien franciser tout ce qui me tombe sous la main), il faut qu'il
contienne un sous-répertoire CVS. Dedans tu trouveras un fichier Root,
qui donne le chemin du chais (et qui t'évite de retaper le "-d" de "cvs
-d ..." à chaque nouvelle commande dans ton répertoire versionné), un
fichier Repository qui donne le chemin dans le chais et un Entries
indiquant ceux qui sont versionnés.

là build.xml et retiré du répertoire de travail, MAIS PAS du répository
où j'ai tjs : build.xml,v

Ouais, donc il aurait effectué le "-f" du "remove -f" avant de voir s'il
connaissait CVS.

si je fais un checkout, ça déconne aussi, j'ai l'impression d'avoir tout
embrouillé ???

Quand tu importes un répertoire Projet, l'import est à faire dans
Projet, tandis que le checkout doit être fait dans le répertoire qui
contiendra Projet (bon, là c'est un peu normal puisque Projet n'existe
pas encore). Attention à la différence de fonctionnement (je me plante
approximativement une fois sur une). Là, si tu est remonté dans
SalutTotoServlet, il a dû te créer un sous-répertoire de
SalutTotoServlet nommé SalutTotoServlet.

Généralement, quand je veux importer sous CVS, je fais (et ce qu'ils
font aussi dans leur manuel):
cd ProjetDeLaMortQuiTue
cvs -d ... import -m "Gnagna" ProjetDeLaMortQuiTue guigui principal
cd ..
mv ProjetDeLaMortQuiTue ProjetDeLaMortQuiTue.2
cvs -d ... co ProjetDeLaMortQuiTue
diff -r ProjetDeLaMortQuiTue*

je sorts du rep, et je fais :

yvonthor$ cvs checkout SalutTotoServlet
cvs checkout: Updating SalutTotoServlet
U SalutTotoServlet/.cvsignore
? SalutTotoServlet/build.xml
? SalutTotoServlet/docs
? SalutTotoServlet/src
? SalutTotoServlet/web

Donc là c'est tout bon au détail près que tu as oublié de renommer le
répertoire entretemps. Donc, euh, que fait-il au juste? Mettons qu'il
voudrait bien resortir le 'src' qu'il connaît en chais CVS mais tombe
sur ton répertoire existant et est un peu gêné car ton répertoire ne
contient pas de sous-répertoire CVS (là c'est de la pure conjecture ce
que je raconte).

ca me donne un nouveau rep CVS dans mon rep "SalutTotoServlet" avec les
fichiers :

Entries
Repository
Root

(j'ai enlevé, à la main, le précédent src/build.xml,v)

Est-ce qu'il t'a créé des répertoires CVS de la même facture dans src,
docs et web? Si non, les "?" du checkout étaient mauvais signe, et il
vaut mieux reprendre proprement (mv SalutTotoServlet SalutTotoServlet.2
et cvs co SalutTotoServlet, avec un diff -r pour te faire une idée de
l'état de l'autre)

puis je fais cvs commit

et là je suis dans (vi je suppose)

Oui, si tu ne donnes pas le commentaire par l'option "-m" de cvs, il te
demande de le rentrer sous ton éditeur par défaut qui a de grandes
chances d'être vi.

à ton avis enlever, à la main le src/build.xml,v
c'est correct ?
j'ai ajouté /build.xml,v après coup...

Oui, fais-le, mais à éviter quand même un minimum une fois que le projet
sera en route, pour préserver les log. Là comme le log ne devait
contenir que "Initial import", ça ne sera pas une perte pleurée par
beaucoup.

P.S.: si tu souhaites des temps de réponse un peu plus faibles, tu peux
toujours poursuivre par courriel, mon adresse est tout ce qu'il y a de
plus en clair. Au boulot, on n'a pas usenet, mais on peut tout de même
consulter son courrier.

--
Guillaume

yvon.thoravalNO

10/12/2003 à 08:21

Guillaume Outters wrote:

P.S.: si tu souhaites des temps de réponse un peu plus faibles, tu peux
toujours poursuivre par courriel, mon adresse est tout ce qu'il y a de
plus en clair. Au boulot, on n'a pas usenet, mais on peut tout de même
consulter son courrier.

merci beaucoup pour ton aide, maintenant c'est plus clair côté usage de
CVS...

la difficulté, pour moi, était que l'exemple de servlet-tomcat
m'obligeait à apprendre deux choses à la fois : l'architecture d'un
servlet sous tomcat (que je n'ai pas encore pigée) et l'usage de cvs...
--
Yvon Thoraval

CVSROOT et Tomcat

7 réponses

Veuillez sélectionner un problème