Bonjour,
Emacs fait des backups de certains fichiers, et désactive les backups
dans certains cas particuliers: fichiers gérés par système de contrôle
de version (e.g. Subversion) et fichiers qui sont descendants de
certains répertoires (e.g. /tmp, /var/tmp).
Il s'agit du comportement *par défaut*. Trouvez-vous cela normal?
Je pense que l'utilisateur n'est pas forcément au courant qu'il existe
de tels cas particuliers et peut être très désagréablement surpris
quand il ne trouve pas de backup pour le fichier qu'il vient d'effacer
par erreur (c'était mon cas).
Concernant la règle pour les fichiers gérés par système de contrôle de
version, il peut se passer plusieurs heures (voire plusieurs jours)
avec
plusieurs éditions du fichier avant un commit, donc je ne vois pas la
raison de désactiver les backups, tout du moins pour le comportement par
défaut. Ceci, même si la majorité des utilisateurs utilisant un système
de contrôle de version préfère l'absence de backup pour ces fichiers.
Bonjour,
Emacs fait des backups de certains fichiers, et désactive les backups
dans certains cas particuliers: fichiers gérés par système de contrôle
de version (e.g. Subversion) et fichiers qui sont descendants de
certains répertoires (e.g. /tmp, /var/tmp).
Il s'agit du comportement *par défaut*. Trouvez-vous cela normal?
Je pense que l'utilisateur n'est pas forcément au courant qu'il existe
de tels cas particuliers et peut être très désagréablement surpris
quand il ne trouve pas de backup pour le fichier qu'il vient d'effacer
par erreur (c'était mon cas).
Concernant la règle pour les fichiers gérés par système de contrôle de
version, il peut se passer plusieurs heures (voire plusieurs jours)
avec
plusieurs éditions du fichier avant un commit, donc je ne vois pas la
raison de désactiver les backups, tout du moins pour le comportement par
défaut. Ceci, même si la majorité des utilisateurs utilisant un système
de contrôle de version préfère l'absence de backup pour ces fichiers.
Bonjour,
Emacs fait des backups de certains fichiers, et désactive les backups
dans certains cas particuliers: fichiers gérés par système de contrôle
de version (e.g. Subversion) et fichiers qui sont descendants de
certains répertoires (e.g. /tmp, /var/tmp).
Il s'agit du comportement *par défaut*. Trouvez-vous cela normal?
Je pense que l'utilisateur n'est pas forcément au courant qu'il existe
de tels cas particuliers et peut être très désagréablement surpris
quand il ne trouve pas de backup pour le fichier qu'il vient d'effacer
par erreur (c'était mon cas).
Concernant la règle pour les fichiers gérés par système de contrôle de
version, il peut se passer plusieurs heures (voire plusieurs jours)
avec
plusieurs éditions du fichier avant un commit, donc je ne vois pas la
raison de désactiver les backups, tout du moins pour le comportement par
défaut. Ceci, même si la majorité des utilisateurs utilisant un système
de contrôle de version préfère l'absence de backup pour ces fichiers.
En ce qui concerne /tmp et /var/tmp, ce sont les répertoires unix
pour les fichiers temporaires du système. De part leur nature
"auto-destructrice", on n'est pas censé travailler sur un fichier
important directement dans ces répertoires, si tant est qu'il y en
ait un.
> Concernant la règle pour les fichiers gérés par système de contrôle de
> version, il peut se passer plusieurs heures (voire plusieurs jours)
C'est trop. Tu mets chaque jour de travail à la merci du crash disque,
penses-y :)
En source control, en principe le commit doit être fait le plus souvent
possible tant que ça ne met pas en doute l'intégrité de la base (genre
ça compile plus). Si dans la pratique ce n'est pas possible (plusieurs
jours de travail sur une nouvelle feature, gros chamboulage...), CVS et
Subversion proposent un système de branches pour ne pas déranger la
racine du projet (voir main-line, trunk, branches, tags).
En ce qui concerne /tmp et /var/tmp, ce sont les répertoires unix
pour les fichiers temporaires du système. De part leur nature
"auto-destructrice", on n'est pas censé travailler sur un fichier
important directement dans ces répertoires, si tant est qu'il y en
ait un.
> Concernant la règle pour les fichiers gérés par système de contrôle de
> version, il peut se passer plusieurs heures (voire plusieurs jours)
C'est trop. Tu mets chaque jour de travail à la merci du crash disque,
penses-y :)
En source control, en principe le commit doit être fait le plus souvent
possible tant que ça ne met pas en doute l'intégrité de la base (genre
ça compile plus). Si dans la pratique ce n'est pas possible (plusieurs
jours de travail sur une nouvelle feature, gros chamboulage...), CVS et
Subversion proposent un système de branches pour ne pas déranger la
racine du projet (voir main-line, trunk, branches, tags).
En ce qui concerne /tmp et /var/tmp, ce sont les répertoires unix
pour les fichiers temporaires du système. De part leur nature
"auto-destructrice", on n'est pas censé travailler sur un fichier
important directement dans ces répertoires, si tant est qu'il y en
ait un.
> Concernant la règle pour les fichiers gérés par système de contrôle de
> version, il peut se passer plusieurs heures (voire plusieurs jours)
C'est trop. Tu mets chaque jour de travail à la merci du crash disque,
penses-y :)
En source control, en principe le commit doit être fait le plus souvent
possible tant que ça ne met pas en doute l'intégrité de la base (genre
ça compile plus). Si dans la pratique ce n'est pas possible (plusieurs
jours de travail sur une nouvelle feature, gros chamboulage...), CVS et
Subversion proposent un système de branches pour ne pas déranger la
racine du projet (voir main-line, trunk, branches, tags).
Je ne vois pas ce que tu entends par "auto-destructrice". /tmp peut être
effacé lors d'un reboot, mais au moins avec Linux, c'est optionnel. Et
/var/tmp n'est jamais effacé après un reboot (d'après ce qu'on m'a dit,
c'est *la* différence avec /tmp).
à la main (que ce soit par "svn ci" ou par scp, suivant le cas).
Pense aussi au cas d'un travail hors-réseau (de manière
exceptionnelle).
Donc AMHA, soit Emacs devrait faire un backup de tous les fichiers par
défaut, soit ne faire aucun backup. Ainsi, aucune surprise.
Je ne vois pas ce que tu entends par "auto-destructrice". /tmp peut être
effacé lors d'un reboot, mais au moins avec Linux, c'est optionnel. Et
/var/tmp n'est jamais effacé après un reboot (d'après ce qu'on m'a dit,
c'est *la* différence avec /tmp).
à la main (que ce soit par "svn ci" ou par scp, suivant le cas).
Pense aussi au cas d'un travail hors-réseau (de manière
exceptionnelle).
Donc AMHA, soit Emacs devrait faire un backup de tous les fichiers par
défaut, soit ne faire aucun backup. Ainsi, aucune surprise.
Je ne vois pas ce que tu entends par "auto-destructrice". /tmp peut être
effacé lors d'un reboot, mais au moins avec Linux, c'est optionnel. Et
/var/tmp n'est jamais effacé après un reboot (d'après ce qu'on m'a dit,
c'est *la* différence avec /tmp).
à la main (que ce soit par "svn ci" ou par scp, suivant le cas).
Pense aussi au cas d'un travail hors-réseau (de manière
exceptionnelle).
Donc AMHA, soit Emacs devrait faire un backup de tous les fichiers par
défaut, soit ne faire aucun backup. Ainsi, aucune surprise.
Bonjour,
Emacs fait des backups de certains fichiers, et désactive les backups
dans certains cas particuliers: fichiers gérés par système de contrôle
de version (e.g. Subversion) et fichiers qui sont descendants de
certains répertoires (e.g. /tmp, /var/tmp).
Il s'agit du comportement *par défaut*. Trouvez-vous cela normal?
Bonjour,
Emacs fait des backups de certains fichiers, et désactive les backups
dans certains cas particuliers: fichiers gérés par système de contrôle
de version (e.g. Subversion) et fichiers qui sont descendants de
certains répertoires (e.g. /tmp, /var/tmp).
Il s'agit du comportement *par défaut*. Trouvez-vous cela normal?
Bonjour,
Emacs fait des backups de certains fichiers, et désactive les backups
dans certains cas particuliers: fichiers gérés par système de contrôle
de version (e.g. Subversion) et fichiers qui sont descendants de
certains répertoires (e.g. /tmp, /var/tmp).
Il s'agit du comportement *par défaut*. Trouvez-vous cela normal?
Aussi le fait que /tmp peut-être très petit (typiquement, en tmpfs, la
moitié de ta RAM). Par exemple, un logiciel de gravure qui met son
image iso temporaire dans /tmp, c'est une connerie.
> à la main (que ce soit par "svn ci" ou par scp, suivant le cas).
^^^
Remplace-moi vite cet ancêtre par un rsync ;-).
> Pense aussi au cas d'un travail hors-réseau (de manière
> exceptionnelle).
D'où l'intérêt des systèmes décentralisés (git, hg, bzr, darcs, ...)
> Donc AMHA, soit Emacs devrait faire un backup de tous les fichiers par
> défaut, soit ne faire aucun backup. Ainsi, aucune surprise.
Je suis aussi de cet avis.
Les fichiers~ sont moins utiles pour les répertoires gérés par un
gestionnaire de version, mais vu ce qu'ils coûtent (combien de Mo sont
occupés par des fichiers textes sur votre disque dur de 100Go ? Moi,
ce qui bouffe de la place, c'est clairement pas les trucs que j'édite
avec Emacs), pourquoi s'en priver ?
Aussi le fait que /tmp peut-être très petit (typiquement, en tmpfs, la
moitié de ta RAM). Par exemple, un logiciel de gravure qui met son
image iso temporaire dans /tmp, c'est une connerie.
> à la main (que ce soit par "svn ci" ou par scp, suivant le cas).
^^^
Remplace-moi vite cet ancêtre par un rsync ;-).
> Pense aussi au cas d'un travail hors-réseau (de manière
> exceptionnelle).
D'où l'intérêt des systèmes décentralisés (git, hg, bzr, darcs, ...)
> Donc AMHA, soit Emacs devrait faire un backup de tous les fichiers par
> défaut, soit ne faire aucun backup. Ainsi, aucune surprise.
Je suis aussi de cet avis.
Les fichiers~ sont moins utiles pour les répertoires gérés par un
gestionnaire de version, mais vu ce qu'ils coûtent (combien de Mo sont
occupés par des fichiers textes sur votre disque dur de 100Go ? Moi,
ce qui bouffe de la place, c'est clairement pas les trucs que j'édite
avec Emacs), pourquoi s'en priver ?
Aussi le fait que /tmp peut-être très petit (typiquement, en tmpfs, la
moitié de ta RAM). Par exemple, un logiciel de gravure qui met son
image iso temporaire dans /tmp, c'est une connerie.
> à la main (que ce soit par "svn ci" ou par scp, suivant le cas).
^^^
Remplace-moi vite cet ancêtre par un rsync ;-).
> Pense aussi au cas d'un travail hors-réseau (de manière
> exceptionnelle).
D'où l'intérêt des systèmes décentralisés (git, hg, bzr, darcs, ...)
> Donc AMHA, soit Emacs devrait faire un backup de tous les fichiers par
> défaut, soit ne faire aucun backup. Ainsi, aucune surprise.
Je suis aussi de cet avis.
Les fichiers~ sont moins utiles pour les répertoires gérés par un
gestionnaire de version, mais vu ce qu'ils coûtent (combien de Mo sont
occupés par des fichiers textes sur votre disque dur de 100Go ? Moi,
ce qui bouffe de la place, c'est clairement pas les trucs que j'édite
avec Emacs), pourquoi s'en priver ?
Oui, je trouve cela tout à fait normal et pratique.
Maintenant, vous pouvez trouver cela embêtant dans votre cas. Pour ce
qui concerne les fichiers utilisant un système de contrôle de version,
c'est la variable 'vc-make-backup-files' qui détermine si ils
utilisent le système de backup ou non. Par défaut, la valeur est
'nil'. Si vous la placez à 't', vous aurez vos backups comme vous le
souhaitez.
Oui, je trouve cela tout à fait normal et pratique.
Maintenant, vous pouvez trouver cela embêtant dans votre cas. Pour ce
qui concerne les fichiers utilisant un système de contrôle de version,
c'est la variable 'vc-make-backup-files' qui détermine si ils
utilisent le système de backup ou non. Par défaut, la valeur est
'nil'. Si vous la placez à 't', vous aurez vos backups comme vous le
souhaitez.
Oui, je trouve cela tout à fait normal et pratique.
Maintenant, vous pouvez trouver cela embêtant dans votre cas. Pour ce
qui concerne les fichiers utilisant un système de contrôle de version,
c'est la variable 'vc-make-backup-files' qui détermine si ils
utilisent le système de backup ou non. Par défaut, la valeur est
'nil'. Si vous la placez à 't', vous aurez vos backups comme vous le
souhaitez.
D'accord, mais je rappelle que le problème est le comportement par
défaut. Tout le monde n'est pas forcément au courant de l'absence de
backups dans des cas particuliers, et c'est cela qui pose problème,
AMHA.
D'ailleurs, quand on fait un C-x C-w sous Emacs et qu'on donne un nom
de fichier déjà existant, Emacs demande toujours confirmation, même
si le fichier en question est géré par Subversion, rendant le C-x C-w
moins pratique. N'y a-t-il pas là un manque de cohérence?
D'accord, mais je rappelle que le problème est le comportement par
défaut. Tout le monde n'est pas forcément au courant de l'absence de
backups dans des cas particuliers, et c'est cela qui pose problème,
AMHA.
D'ailleurs, quand on fait un C-x C-w sous Emacs et qu'on donne un nom
de fichier déjà existant, Emacs demande toujours confirmation, même
si le fichier en question est géré par Subversion, rendant le C-x C-w
moins pratique. N'y a-t-il pas là un manque de cohérence?
D'accord, mais je rappelle que le problème est le comportement par
défaut. Tout le monde n'est pas forcément au courant de l'absence de
backups dans des cas particuliers, et c'est cela qui pose problème,
AMHA.
D'ailleurs, quand on fait un C-x C-w sous Emacs et qu'on donne un nom
de fichier déjà existant, Emacs demande toujours confirmation, même
si le fichier en question est géré par Subversion, rendant le C-x C-w
moins pratique. N'y a-t-il pas là un manque de cohérence?
Sinon, d'accord avec vous pour proposer l'inversion du réglage par
défaut. Personnellement, cela ne me dérangerait absolument pas.
Sinon, d'accord avec vous pour proposer l'inversion du réglage par
défaut. Personnellement, cela ne me dérangerait absolument pas.
Sinon, d'accord avec vous pour proposer l'inversion du réglage par
défaut. Personnellement, cela ne me dérangerait absolument pas.
Heu, là, je ne vois pas. La confirmation de l'écrasement du contenu
d'un fichier par un autre me semble tout à fait pertinente quel que
soit le contexte....
Heu, là, je ne vois pas. La confirmation de l'écrasement du contenu
d'un fichier par un autre me semble tout à fait pertinente quel que
soit le contexte....
Heu, là, je ne vois pas. La confirmation de l'écrasement du contenu
d'un fichier par un autre me semble tout à fait pertinente quel que
soit le contexte....
Voir des copies de tous les mails que j'écris s'accumuler
m'ememrderait passablement.
Voir des copies de tous les mails que j'écris s'accumuler
m'ememrderait passablement.
Voir des copies de tous les mails que j'écris s'accumuler
m'ememrderait passablement.
