PCL-CVS et call-process
Le
drkm
Bonsoir
Je tente d'apprendre PCL-CVS. Mon working directory est à jour.
Lorsque je fais :
C-u C-x C-f [ . . . ] / C V S <RET>
il m'affiche la bonne liste de fichiers, avec les bons numéros de
révision, mais tous avec le status « Modified », alors que tout est à
jour. C'est en tout cas ce que me dit CVS lancé à la main.
Je ne sais pas si le problème vient de ce que j'utilise Cygwin.
Mais un truc bizarre est que lorsque je fais :
(setq cvs-program "c:/cygwin/bin/cvs.exe")
(call-process cvs-program nil t nil "-v")
(call-process cvs-program)
les deux appels à `call-process()' me donnent respectivement :
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
call-process("c:/cygwin/bin/cvs.exe" nil t nil "-v")
eval((call-process cvs-program nil t nil "-v"))
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
et :
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
call-process("c:/cygwin/bin/cvs.exe")
eval((call-process cvs-program))
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
Tout cela est très étrange. Quelqu'un a-t-il une piste ?
PS: Toujours plus étrange. En écrivant cet article, je me suis
retrouvé dans un buffer d'aide à exécuter par erreur :
M-x ( c a l l - p r o c e s s c v s - p r o g r a m ) <RET>
qui retournait 0x01. J'ai réussi à l'évaluer plusieurs fois. Mais
une fois le buffer tué, je n'ai pas réussi à le réévaluer sans
erreur Vraiment bizarre.
PPS: Merci Matthieu, pour le `fill-nobreak-predicate'. Il marche
nickel.
--drkm
Je tente d'apprendre PCL-CVS. Mon working directory est à jour.
Lorsque je fais :
C-u C-x C-f [ . . . ] / C V S <RET>
il m'affiche la bonne liste de fichiers, avec les bons numéros de
révision, mais tous avec le status « Modified », alors que tout est à
jour. C'est en tout cas ce que me dit CVS lancé à la main.
Je ne sais pas si le problème vient de ce que j'utilise Cygwin.
Mais un truc bizarre est que lorsque je fais :
(setq cvs-program "c:/cygwin/bin/cvs.exe")
(call-process cvs-program nil t nil "-v")
(call-process cvs-program)
les deux appels à `call-process()' me donnent respectivement :
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
call-process("c:/cygwin/bin/cvs.exe" nil t nil "-v")
eval((call-process cvs-program nil t nil "-v"))
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
et :
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
call-process("c:/cygwin/bin/cvs.exe")
eval((call-process cvs-program))
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
Tout cela est très étrange. Quelqu'un a-t-il une piste ?
PS: Toujours plus étrange. En écrivant cet article, je me suis
retrouvé dans un buffer d'aide à exécuter par erreur :
M-x ( c a l l - p r o c e s s c v s - p r o g r a m ) <RET>
qui retournait 0x01. J'ai réussi à l'évaluer plusieurs fois. Mais
une fois le buffer tué, je n'ai pas réussi à le réévaluer sans
erreur Vraiment bizarre.
PPS: Merci Matthieu, pour le `fill-nobreak-predicate'. Il marche
nickel.
--drkm
Poser une question
Bonsoir,
Si je puis me permettre de donner mon avis, apprendre CVS et outils
connexes aujourd'hui n'est pas une super idée.
CVS est un gestionnaire de version pleins de limitations assez
pénibles (en particulier, la gestion des répertoires et le renommage
des fichiers). Le successeur logique de CVS, c'est subversion[1], et
oh, miracle, il y a un mode Emacs pour ça aussi[2] !
Après, il y a d'autres gestionnaires de version qui suivent des voies
différentes, mais très intéressantes également. Personnellement,
j'utilise Arch[3], <pub> et, là aussi, il y a un mode Emacs[4] !</pub>
[1] http://subversion.tigris.org/
[2] http://www.xsteve.at/prg/vc_svn/index.html
[3] http://gnuarch.org/
[4] http://wiki.gnuarch.org/moin.cgi/xtla
Je ne connaissais pas cette méthode. Je faisais M-x cvs-update RET.
[...]
[...]
[...]
Très bizarre, tout ça. Un simple call-process qui plante comme ça ...
Que vaut la variable `default-directory' dans le buffer d'ou tu essaye
d'executer (call-process ...) ? Est-ce que tu arrives à faire un
`call-process' sur un autre programme dans le même buffer ?
--
Matthieu
Permets-toi, permets-toi ...
[...]
Merci pour ces explications et ces liens. Néanmoins, CVS est fort
employé, il me semble. Ce n'est pas un argument pour l'employer sur
un nouveau projet, mais je n'ai pas le choix pour mon projet sur
SourceForge. C'est CVS, point.
Je pense avoir vu quelque part qu'ils n'excluent de fournir un
support pour Subversion dans le futur. Si c'est le cas, je pourrai
toujours y jeter un oeil, mais d'ici là, je n'ai pas le choix.
Si je me souviens bien, c'est équivalent.
Surtout en ce qui concerne l'erreur, `(wrong-type-argument stringp
nil)'. J'ai jeté un oeil rapidement à l'implémentation de
`Fcall_process()', et je n'ai rien trouvé.
Bingo. J'ai un peu galèré, mais apparemment, `default-directory'
vaut "~" et cela n'est pas bon. Avec "~/", ça fonctionne. Est-ce
normal ?
Mouais. _`call-process()'_ fonctionne. Mais PCL-CVS semble
toujours avoir le même problème, tous les fichiers sont à
« Modified ». De toute façon, le problème de `call-process()' ne doit
pas en être la cause, puisqu'il semble faire un change directory.
Sans doute est-ce relatif à une option de PCL-CVS. Il faudrais que
j'investigue un peu, mais je n'ai pas le temps ce soir. Il me semble
tout de même bizarre que PCL-CVS ne me retourne pas d'erreur. Aucun
message, aucune demande de mot de passe, aucun délai. Ce n'est pas
possible qu'il exécute `cvs(1)'. Mais il reste silencieux.
Étrange ...
Merci pour le filon, j'investiguerai plus loin le moment venu.
--drkm
,----[ C-h v default-directory RET ]
| default-directory's value is "~/"
| Local in buffer *followup to drkm |
| Documentation:
| Name of default directory of current buffer. Should end with slash.
| ^^^^^^^^^^^^^^^^^^^^^
| Each buffer has its own value of this variable. To change the
| default directory, use function `cd'.
`----
Effectivement, si la variable ne se termine pas par un slash, le
comportement de pas mal de fonctions est completement déconnant.
Dans le buffer *cvs*, il te dit quelle est la dernière commande qu'il
a executé. Regardes la sortie de la commande si tu la lances à la
main.
Sinon, il va falloir débugger, probablement du coté de
`cvs-update-filter'.
--
Matthieu
J'ai vérifié, c'est équivalent à `cvs-examine()', plutôt. Du moins,
c'est ce qu'il renseignent dans Néanmoins, `cvs(1)' n'est exécuté que lors de l'appel de
`cvs-examine()', pas par :
C-u C-x C-f [ . . . ] / C V S <RET>
--drkm
Un peu gros :-/. Merci.
Oui. Mais justement, le problème était qu'il me donnait des
résultats totalement différents de ce que j'obtenais à la main. Mais
sans me signaler d'erreur de son côté.
En fait, j'ai progressé depuis. J'arrive à lancer effectivement
`cvs(1)'. Mais avec SSH, requis par SF, il doit me demander un mot de
passe de manière interactive, au lieu de quoi il n'affiche rien, et je
vois que `cvs(1)' et `ssh(1)' tournent (sans doute en attente d'une
entrée).
Je vais donc me tourner vers les MLs de PCL-CVS, si personne n'a
expérimenté ce problème ici.
Merci.
--drkm