Un truc qui m'est arrivé le week-end dernier... Je crée un nouveau répertoire dans le projet sur lequel je bosse, je bosse dedans sur des fichiers python pendant l'après-midi, puis j'ai besoin de comiter dans mon svn. Donc voilà comment ça se passe :
$ svn add dir
Adding fichier
....
Dans ma tete « merde, ce con ajoute tous les fichiers dans le répertoire, au lieu juste le répertoire comme cvs, grmbl... Il m'a ajouté les .pyc et des fichier backup~. Pas grave, je fais un delete ... »
$ svn delete dir
are you sure, --force bla bla bla
$ svn --force delete dir (dans ma tete « je devrais peut etre copier mes fichiers ailleurs, on sait jamais, bon allez entrée quand meme c'est pas possible que »)
$ ls dir
ls: dir: Aucun fichier ou répertoire de ce type
AAAAAAaaaargh... Putain ce con touche à mon filesystem local quand je fais un delete !$@ de chiotte... Alors comme j'étais sur un vserver avec reiserfs j'ai utilisé l'astuce postée ici meme pour retrouver mon fichier avec reiserfsck et ça m'a niqué pleins de fichiers, j'ai réussi à récupérer mes fichiers avec des grep à la main dans /dev
La grosse interrogation que j'ai alors eu, c'est qu'on est en 2005, on n'est pas en 1998, pourquoi :
1. Je n'ai toujours pas la possibilité facilement de "undelete" des fichiers qui ont été effacés sur le filesystem ???? Putain on est au 21ème siècle, on a des disques de 200Go pour rien, etc... Et je parle pas d'un alias rm=mv ~/poubelle, vu que là c'est svn qui l'a viré.
2. Pourquoi je n'ai toujours pas de système de fichier journalisé en interne pour pouvoir revenir à des versions ultérieures ???
Journal Filesystem "versionalisé" ? (!$@ de subversion)
1
avr.
2005
# rho
Posté par Pinaraf . Évalué à 6.
Quand on te dit "Are you sure", y'a bien des raisons !
Sinon, pour une corbeille : http://www.shirka.org/recycled4linux/(...)
Et un système de fichier avec gestion des versions : c'est pas si simple... Il y a probablement des implémentations utilisant fuse, je te laisse chercher. Ou just do it.
[^] # Re: rho
Posté par Thierry . Évalué à 7.
Oui, enfin, VMS faisait déja ça il y a plus de vingt ans, hein...
[^] # \o/ J'ai trouvé wayback qui utile l'architecture FUSE(user file systems)
Posté par free2.org . Évalué à 5.
http://wayback.sourceforge.net/(...)
[^] # Re: \o/ J'ai trouvé wayback qui utile l'architecture FUSE(user file syst
Posté par free2.org . Évalué à 4.
http://freshmeat.net/projects/copyfs/(...)
et pour les backups versionnés incrémentaux:
http://freshmeat.net/projects/histbackup/(...)
et c'est pas des poissons non plus !
# Farpaitement !
Posté par harbort1 . Évalué à 2.
[^] # Re: Farpaitement !
Posté par calandoa . Évalué à -1.
Surtout que le filesystem qui implémenterait cette fonctionnalité perdrait forcement en performance, t'imagine la honte lors du prochain benchmark sur slashdot? « Le nouveau système de fichier XXX qui n'efface que 245 fichiers par secondes, soit 83% de moins que ext3, 78% de moins que reiser4, etc, xfs, jfs, etc... » Mais quel haxor voudrait utiliser une merde pareille? 245 fichiers à la seconde, ahahah quelle blague, le système serait totallement inutilisable! Imagine un peu comment ça plomberait un serveur Apache quadriXeon 3.6 Ghz avec 6 Go de RAM qui répond à 37883500 requêtes par seconde!!! --- Ah? il y a un mamie qui m'interrompt... oui? ah bon? vous effacez un fichier tous les 3 mois? Tire toi connase, on en a rien à foutre de ta gueule, l'informatique, ç'est reservé aux warlords, et les warlords ça ne fait jamais d'erreurs...
# Réponse au 1
Posté par Florent Bayle (site web personnel) . Évalué à 3.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Parce que ...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Donc en fait parce que je ne lis pas le manuel, je niquer 10h de boulot. Bien sûr que c'est une erreur de ma part, mais je ne vois pas en quoi une commande svn touche à mes fichiers locaux, surtout dans le cas de remove...
De toute façon, même avec une possibilité "undelete" bas niveau, le problème ne fait qu'être déplacé : en effet, tu auras toujours quelqu'un pour se plaindre qu'après avoir nettoyé les anciens fichiers effacés pour libérer de la place, il ne sont plus récupérables.
Ouais l'utilisateur a toujours tort quoi ... C'est malheureusement une manière de penser qui est courante dans le monde du libre, et c'est bien ce que je lui reproche.
[^] # Re: Parce que ...
Posté par Antoine . Évalué à 3.
Il me semble que la commande équivalente sous CVS le fait aussi.
[^] # Re: Parce que ...
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Parce que ...
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Parce que ...
Posté par Aurélien Bompard (site web personnel) . Évalué à 7.
Un peu comme svn rm --force, quoi...
[^] # Re: Parce que ...
Posté par Sébastien Bonnefoy (site web personnel) . Évalué à 4.
Mais j'ai une autre question... svn (je connais pas trop) c'est un système de gestion de conf, donc normalement, il a du garder une version des fichers qui ont été suprimé, non? Pourquoi il suffit pas de recupérer la dernière version dans ce cas?
[^] # Re: Parce que ...
Posté par fabb . Évalué à 9.
Fabien n'a pas mis sont répertoires sur le serveur.
Pour ça il aurait dû faire :
$ svn add rep
$ svn commit <== (rep est sur le serveur)
$ svn rm rep # suppression locale (mais pas sur le serveur)
puis
$ svn commit # suppression sur le serveur mais uniquement pour la version HEAD
$ svn merge ... (pour récupérer la version précédente)
OU
$ svn revert # annule la modification locale (c-à-d le "svn rm rep")
Le problème est que Fabien a fait "svn rm rep" au-lieu de "svn revert rep".
"svn revert" est pour annuler les modifications de la version locale (c'est ce qu'il voulait faire).
L'erreur de Fabien découle d'une autre erreur. Il a fait "svn add rep" alors qu'il voulait faire "svn add --non-recursive".
[^] # Re: Parce que ...
Posté par fabb . Évalué à 10.
Là, t'es "facile". Déjà t'es du genre a être dans ce profile (comme tout le monde en fait).
Deux, t'es suffisament grand pour savoir qu'il faut un backup surtout que tu utilises un outil dont tu n'as lu la doc.
Trois, tu n'as pas lu le warning alors que tu ne connais pas svn.
Quatre, tu n'as pas considéré comme important que svn te demande t'utiliser "--force" et donc de réfléchir un peu avant d'aller plus loin.
Cinq, tu as préjugé du comportement d'un outil (t'es trop sûr de toi ?).
Six, tu n'as pas lu la doc.
Je comprend bien qu'on puisse être énervé après une telle "aventure".
Mais ce qui est de ta faute, est de ta faute.
# Plan9+Venti+fossil
Posté par Krunch (site web personnel) . Évalué à 4.
http://plan9.bell-labs.com/magic/man2html/8/venti(...)
http://www.cs.bell-labs.com/sys/doc/venti/venti.html(...)
Sinon il y a un cvsfs qui traine quelque part. Il existe aussi un module noyau (recycled4linux) qui intercepte les appelles à unlink(2) pour déplacer les fichiers supprimés dans un répertoire "poubelle" et une bibliothéque userland (libtrash) qui fait a peut près la même chose.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Réponses
Posté par Boa Treize (site web personnel) . Évalué à 4.
2. Pour revenir à des révisions ultérieures, il va te falloir attendre encore quelques progrès dans le voyage à travers le temps. :-) Ceci dit, tu peux d'ores et déjà t'acheter une Alpha (ou même un VAX) et faire tourner VMS dessus, et tu les auras tes versions -- elles y sont depuis une vingtaine d'années. Ah, y'a même un émulateur VAX pour processeurs IA32, mais ça risque d'être un peu lent.
[^] # Re: Réponses
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Réponses
Posté par Éric (site web personnel) . Évalué à 6.
Non, si nos fichiers ne sont pas récupérables ce n'est pas parce que le système est morderne, c'est parce qu'il n'y a rien prévu pour. Et oui, maintenant que le système devient un peu plus grand publique ça commence à être un manque.
[^] # Re: Réponses
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
Ca a toujours été un manque, sauf qu'avant on pouvait se dire qu'on avait un système récent, pas assez "mur", etc. Maintenant qu'on a un système qui se veut professionnel, en 2005, on pourrait quand même avoir un minimum, et ça ça me semble l'être.
De manière général sur certains points t'as quand même un fossé assez large et qui tend à mon avis (et je ne doute pas que ce n'est pas l'avis de beaucoup de lecteurs ici) à se creuser. Quand tu vois les versions de longhorn qui arrivent ou osX et les évolutions de linux, on se pose des questions (enfin moi je m'en pose).
[^] # Re: Réponses
Posté par TImaniac (site web personnel) . Évalué à 5.
[^] # Re: Réponses
Posté par fabb . Évalué à 5.
[^] # Re: Réponses
Posté par Pooly (site web personnel) . Évalué à 3.
Pour le pb des fichiers effacés par mégarde, il suffit de déplacer le répertoire temporaire des sauvegardes sur un autre path. Vim le fait très bien.
# ;-)
Posté par kolter (site web personnel, Mastodon) . Évalué à -5.
M.
# DragonFly BSD
Posté par lsartran . Évalué à 6.
cf. http://leaf.dragonflybsd.org/mailarchive/kernel/2005-03/msg00038.html
[^] # Re: DragonFly BSD
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: DragonFly BSD
Posté par Pooly (site web personnel) . Évalué à 4.
Heureux pour toi, mes 20 Go sur mon laptop, je trouve pas ça énorme.
[^] # Re: DragonFly BSD
Posté par Juke (site web personnel) . Évalué à 2.
[^] # Re: DragonFly BSD
Posté par mrlem (site web personnel) . Évalué à 4.
Pfiou. Nostalgie quand tu nous tiens.
# Rien n'est perdu !
Posté par Guillaume Bour . Évalué à 10.
Personnellement, c'est un comportement que je trouve normal. D'ailleurs, arch fonctionne de la même façon (tla rm).
Mais, oh miracle, tes fichiers, s'ils ne sont plus accessibles directement, sont toujours présent dans le référentiel.
Vas faire un tour sur le svn book pour savoir comment les récupérer: http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.3(...)
[^] # Re: Rien n'est perdu !
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
Est-ce que je me trompe ?
# Filesystem "versionalisé" ? (!$@ de subversion) : c possible
Posté par beny (site web personnel) . Évalué à 2.
J'y ai déjà pensé il y a quelques temps de cela, cela fait parti d'un de mes futurs sous-projets (inclus dans un projet global). Mais je n'ai pas 10 cerveaux et 20 mains pour coder. Désolé ...
En somme, pour expliquer rapidement aux gens qui se posent la question, c'est un système de versionning qui sera entièrement basé sur du xml et ses technologies (quand je dis entièrement, c'est réellement entièrement : XPath, XPointer, XLink, XQuery, XForms. XSchemas, XSL, (etc. ?)).
L'idée par dessus serait de réaliser un module qui reprendrait les fonctionnalités de ce système pour être intégré sur un système simple et complétement décentralisé (i.e. : via l'abstraction, on se retrouve sur un système de fichiers comme les autres, et en cas d'erreur ou de manipulations importantes, des outils permettent d'accèder directement à l'ensemble du fs versionné) au dessus d'un fs parce que personnellement je n'ai pas les compétences adéquates pour écrire un fs bas-niveau.
Bref, comme je l'ai déjà dit, je n'ai paas 10 cerveaux et 20 mains pour coder, donc soit ca attendra, soit des gens le feront à ma place.
[^] # Re: Filesystem "versionalisé" ? (!$@ de subversion) : c possible
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Filesystem "versionalisé" ? (!$@ de subversion) : c possible
Posté par gc (site web personnel) . Évalué à 2.
Par exemple si je mets à jour la taille et la position de la fenêtre principale d'une appli gtk directement avec un appel à cette API (j'en demande pas énorme, mettre à jour un élément fils de l'élément racine, sur un document XML qui contient moins de 10 éléments au total) dans le callback gtk qui va bien, ben ça fait ramer gtk quand je redimensionne la fenêtre.
Dans le même ordre d'idée, dès que j'ai plus de 50 éléments dans un autre fichier, il commence à falloir plusieurs secondes sur un p4 pour enlever 10 éléments et en rajouter 10 autres.
Au final je vais certainement devoir "transcrire" une structure de donnée en hashtable ruby à plusieurs niveaux car modifier directement le document XML rame trop (pourtant sa structure en arbre se prête très bien à son utilisation directe).
[^] # Re: Filesystem "versionalisé" ? (!$@ de subversion) : c possible
Posté par Tonton Th (Mastodon) . Évalué à 10.
Quand tu as un problème informatique, il y a toujours une bonne âme pour te suggerer XML. Tu as maintenant 2 problèmes.
[^] # Re: Filesystem "versionalisé" ? (!$@ de subversion) : c possible
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Tu as oublié la question 3
Posté par Lucas . Évalué à 2.
[^] # Re: Tu as oublié la question 3
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
Toi tu fais des sauvegardes tout le temps sur ton home ?
[^] # Re: Tu as oublié la question 3
Posté par Lucas Bonnet . Évalué à 2.
http://www.nongnu.org/rdiff-backup/(...)
[^] # Re: Tu as oublié la question 3
Posté par icyfemur . Évalué à 5.
[^] # rsnapshot
Posté par Big Pete . Évalué à 2.
http://www.rsnapshot.org/(...)
C'est basé sur rsync avec des hardlinks sur les fichiers qui n'ont pas été modifiés. Par defaut, il fait des sauvegardes horaires.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
# bien trouvé !
Posté par Antoine . Évalué à 0.
$ svn --force delete dir (dans ma tete « je devrais peut etre copier mes fichiers ailleurs, on sait jamais, bon allez entrée quand meme c'est pas possible que »)
Pas mal ton poisson d'avril :))
2. Pourquoi je n'ai toujours pas de système de fichier journalisé en interne pour pouvoir revenir à des versions ultérieures ???
C'est très simple, tu n'as qu'à utiliser subversion pour tes fichiers ! :D
("revenir à des versions ultérieures", c'est assez fort en soi)
[^] # Re: bien trouvé !
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 2.
# svn
Posté par fabb . Évalué à 2.
Si tu fais une erreur sur ta version local, pour revenir en arrière il faut utiliser "svn revert".
> $ svn delete dir
> are you sure, --force bla bla bla
C'est le "bla bla bla" qui est important. Ça devait être :
- "svn: 'dir' has local modifications"
> AAAAAAaaaargh... Putain ce con touche à mon filesystem local quand je fais un delete !$@ de chiotte...
C'est normal (mais je comprend ton "agacement").
Il y a trois versions :
- la version locale
- la version de référence (une copie en local de la dernière version HEAD connue)
- la version (en fait les versions) sur le serveur mais plus notament la version HEAD
Il n'y a pas de commande pour manipuler directement la version de référence.
La version local est manipulé avec les commandes svn si l'url est un fichier local.
La version sur le serveur est manupulé avec les commandes svn si l'url est le serveur.
Évidemment il y a des exceptions (comme par exemple "svn commit").
Donc, lorsque tu fais "svn rm fichier", ça supprime le fichier local. Svn demande l'utilisation de "--force" s'il n'a pas de version de référence (ni sur le serveur puisque la version de référence locale est la dernière version connue sur le serveur).
T'es tombé dans le troll :
- svn c'est comme cvs
Lire l'annexe A : Subversion for CVS Users
http://svnbook.red-bean.com/en/1.1/apa.html(...)
Puis, je finis par un RTFM bien mérité car la doc Subversion est vraiment superbe :
http://svnbook.red-bean.com/en/1.1/index.html(...)
[^] # Re: svn
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 1.
$ mkdir toto
$ touch toto/plop1
$ touch toto/plop2
$ svn add toto
A toto
A toto/plop1
A toto/plop2
$ svn remove toto
svn: Use --force to override this restriction
svn: 'toto' has local modifications
$ svn --force remove toto
D toto
$ ls toto
(là c'est mort...)
Je ne comprends pas là, en gros le truc est censé me dire que la commande remove fait des modifications locale, ou que toto est localement différent que sur le repository. Pour moi là il devrait m'afficher un :
Warning: remove will _erase_ your local file(s) !!!
Ce serait un tant soit peu plus explicite...
[^] # Re: svn
Posté par Antoine . Évalué à 0.
Warning: remove will _erase_ your local file(s) !!!
Ce serait un tant soit peu plus explicite...
En effet, le message d'erreur est franchement couillon. AMA, un bug report s'impose (avec un niveau du genre "major" ou "critical").
[^] # Re: svn
Posté par Florimond S. (site web personnel) . Évalué à 2.
Est-ce que ça empêche gravement d'utiliser le logiciel ? Est-ce que ce bug le fait planter ? Non, et non.
Un bug report parait effectivement une bonne idée quand un message d'erreur n'est pas totalement adéquat, mais certainement pas avec un niveau critique qui est normalement réservé aux bugs à cause desquels le logiciel failli totalement à sa mission - ici on a un utilisateur qui n'a pas lu la documentation, c'est lui qui prend un bug critique.
[^] # Re: svn
Posté par Antoine . Évalué à 2.
Un logiciel qui efface des fichiers sans l'annoncer clairement, ce n'est pas un logiciel qui faillit à sa mission ?
On doit pas utiliser l'informatique pour la même chose...
[^] # Re: svn
Posté par Florimond S. (site web personnel) . Évalué à 2.
En tout cas moi je n'utilise pas l'informatique pour faire de la mauvaise foi.
[^] # Re: svn
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: svn
Posté par Florimond S. (site web personnel) . Évalué à 7.
où ai-je jamais dit que le message était clair ?
J'ai dit que ça aurait dû éveiller ton attention, et ça n'a manifestement pas été le cas. Le bug critique, tu le prends, tu le partages en deux, et tu t'en gardes la moitié, merci.
L'ironie sur l'expérience, tu peux te la garder tout court, parce que précisement si tu en avais autant que tu veux bien le faire croire ça n'aurait pas manqué de te faire réagir.
[^] # Re: svn
Posté par Volnai . Évalué à 2.
[^] # Re: svn
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: svn
Posté par fabb . Évalué à 1.
Si svn te dit "attention il y a des modifications locales", c'est pour quoi ?
Pour ce type d'info, il y a "svn status".
> Je ne comprends pas là, en gros le truc est censé me dire que la commande remove fait des modifications locale
La commande remove fait *toujours* des modifications locales. Le warning est lorsque tu vas perdre de modifications locales.
Autre exemple :
[admin@one trunk]$ svn status
M kernel-2.6.spec
[admin@one trunk]$ svn remove kernel-2.6.spec
svn: Use --force to override this restriction
svn: 'kernel-2.6.spec' has local modifications
[^] # Re: svn
Posté par fabb . Évalué à 3.
delete (del, remove, rm): Remove files and directories from version control.
usage: 1. delete PATH...
2. delete URL...
1. Each item specified by a PATH is scheduled for deletion upon
the next commit. Files, and directories that have not been
committed, are immediately removed from the working copy.
PATHs that are, or contain, unversioned or modified items will
not be removed unless the --force option is given.
# Translator Hurd
Posté par Matthieu Lemerre (site web personnel) . Évalué à 2.
Donc je t'invite a coder ce translator pour le Hurd :) (si il n'existe pas deja d'ailleurs)
http://l-lang.org/ - Conception du langage L
# Petite dose de mauvaise fois
Posté par Guillaume Knispel . Évalué à 5.
Certe svn n'a pas l'air tout blanc dans la cas qui nous interresse, mais :
1) GNU's not Unix, si en plus tu rajoute GNU's not VMS et tout un tas de features de la mort qui tue tu va certes te retrouver avec un systeme sûr pour les cret^W utilisateurs pressés qui lisent pas les manuels et qui présupose un fonctionnement des outils uniquement a partir de leur expériences personelles précédente ce qui n'a pas lieu d'être étant donné la variété d'outils de n'importe quel usage et de comportements subtilement différents disponibles aujourd'hui et l'expérience et le parcours personnel de chacun qui est forcement différent, mais de plus en plus lourd de plus en plus lent, de plus en plus consommateur et qui risque fort de ne plus convenir à d'autres (moi par exemple). Ceci étant j'ai bien conscience qu'on est déjà malheureusement dans cette voix à l'heure ou je vois des gens proposer sérieusement dans des journaux de faire de l'OOo sur un VM mono en java (pourquoi pas avec un win émulé par Bochs faisant tourné un X en remote sur un tunel ipsec tant qu'ils y sont ?)
Enfin comme plusieurs personnes t'ont déjà répondu il existe des biblio et modules noyau permettant un effacement réversible, donc ton seul tords et de ne pas t'en servir (en plus de virer tes fichiers précieux bien sûr).
2) Ben la même chose que 1 quoi ! Avec en plus la petite variation suivante vu que la question n'etait pas la meme : parce que personne l'a écrit, merde !!! On dirait que chez certains utilisateurs de LL tout leur est du, et que si un outil n'existe pas alors c'est inacceptable, le libre est en danger, qu'on est de retour au siecle précédent, que la construction europenne va s'effond^W^W^W^W MS va nous anéantir... Tu veux pas 100 balles et un mars aussi ? Je suis sûr que si tu payes fort cher une SSLL elle sera ravie de te concevoir ca.
Je conclurais de la façon suivante. - Amis developpeurs d'outils foutez tous des warnings bien puissants à chaque destruction d'octet, pour eviter que les lecteurs de LFR se tapent des "oin j'ai fais un rm -rf / et plus rien ne marche" ' like et aient envit d'y répondre par une réponse plus violente que la plainte. - Amis utilisateurs d'outils venez pas peter les burnes si suite à une faute de votre part le méchant n'ordinateur a fait pété toutes vos données.
[^] # Re: Petite dose de mauvaise fois
Posté par fabb . Évalué à -1.
Et pareil quand tu fais "enregistrer" dans un traitement de texte ?
Pareil que tu fais "delete from ...." ou "update ..." avec un SGBD ?
Désolé, mais ta proposition n'as tout simplement aucun sens.
Quand on fait "svn rm --force" ou ":w!" dans vim on doit savoir ce qu'on fait.
Évidement, il faut guider les utilisateurs pour qu'il ne se fasse pas avoir par quelques cas particuliers (par exemple ":w fichier_existant_et_différent_du_buffer_en_cours"). Mais l'emploi de "--force" (ou de "!" dans vim) doit être fait en connaissance de cause.
[^] # Re: Petite dose de mauvaise fois
Posté par Florimond S. (site web personnel) . Évalué à 1.
[^] # Re: Petite dose de mauvaise fois
Posté par chl (site web personnel) . Évalué à -1.
Je conclurais de la façon suivante. - Amis posteurs de commentaires foutez tous des warnings bien puissants à chaque phrase ironique, pour eviter que les lecteurs de LFR se tapent des "Et pareil quand tu fais "enregistrer" dans un traitement de texte ?
Pareil que tu fais "delete from ...." ou "update ..." avec un SGBD ?" like et aient envit d'y répondre par une réponse plus violente que la plainte. - Amis lecteurs de commentaires venez pas peter les burnes si suite à une lecture rapide de votre part vous ne comprennez pas le méchant posteur ironique.
[^] # Re: Petite dose de mauvaise fois
Posté par totof2000 . Évalué à 3.
pasque si c'est ca t'as oublié les avertissements ....
# INotify
Posté par vrm (site web personnel) . Évalué à 1.
[^] # Re: INotify
Posté par Krunch (site web personnel) . Évalué à 2.
http://fuse.sf.net(...)
http://lufs.sf.net(...)
http://v9fs.sf.net(...) <- implémentation de 9P, le protocol de fs de Plan9, probablement le plus intéressant à long terme
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: INotify
Posté par Sebastien . Évalué à 2.
Je me suis interessé il y a peu à c'teu truc de chez Bell...
Tu utilises (heu au fait tu permets que je te tutoies ;) Plan 9 ou bien juste l'implémentation du système de fichiers ?
Toute info m'intéresse :)
[^] # Re: INotify
Posté par Krunch (site web personnel) . Évalué à 2.
Sinon comme je l'ai dit plus haut, il existe un système de fichier versionnalisé (fossil) implémenté par dessus 9P et donc avec v9fs on est censé pouvoir déjà l'utiliser sous Linux.
A noter que Hurd implémente un système fort similaire à 9P avec ses "translators" (enfin si j'ai bien compris).
[0] "Intro to Plan 9" lightning talk du FOSDEM 2005 (on y parle quand même de v9fs mais soit je m'en souviens pas soit ça a été passé, c'était la dernière présentation et il y avait beaucoup de retard) http://www.ffii.org/~zoobab/bh.udev.org/filez/lightning/2005/19-pla(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# option revert
Posté par nive . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.