Journal Filesystem "versionalisé" ? (!$@ de subversion)

Posté par  (site web personnel, Mastodon) .
Étiquettes : aucune
0
1
avr.
2005
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 ???

  • # rho

    Posté par  . Évalué à 6.

    Tu dois te blamer plus que le système là !
    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.

  • # Farpaitement !

    Posté par  . Évalué à 2.

    Ouai, ben moi aussi j'ai eu des déboires similaires ... pas avec SVN, mais bon, y a des jours où un file system avec versionnage et undelete serait plus qu'appréciable !

    • [^] # Re: Farpaitement !

      Posté par  . Évalué à -1.

      Faut pas exagérer quand même, on va pas demander aux développeurs d'innover, surtout que ça serait quand même assez difficile à implémenter... De plus, ça ne serait qu'une fonctionnalité qui serait juste pratique pour les simples utilisateurs qui font des erreurs, et, honnêtement, ils peuvent aller se faire voire ailleurs si ils sont pas capable de faire plus attention. Il faut quand même rappeler que l'utilisateur est au service de son ordinateur et non le contraire.

      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  (site web personnel) . Évalué à 3.

    Pour le 1), il existe recycled4linux (http://www.shirka.org/recycled4linux/),(...) ou libtrash (http://www.m-arriaga.net/software/libtrash/),(...) qui interceptent les appels système de suppression des fichiers, et mettent les fichier dans une corbeille.

  • # Commentaire supprimé

    Posté par  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Parce que ...

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Si tu lisais le manuel très complet de SVN au lieu de supposer que SVN fonctionne exactement comme CVS, tu n'aurais sûrement pas eu ce problème. Docn à l'évidence, il s'agit d'une erreur de ta part et quelque soit le système mis en place, il y aura toujours un niveau où l'utilisateur produira ce genre d'erreur.

      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  . Évalué à 3.

        mais je ne vois pas en quoi une commande svn touche à mes fichiers locaux, surtout dans le cas de remove...

        Il me semble que la commande équivalente sous CVS le fait aussi.

        • [^] # Re: Parce que ...

          Posté par  (site web personnel) . Évalué à 5.

          Non, il faut d'abbord supprimer le fichier puis faire un remove avec CVS.
          cvs remove foobar
          cvs server: file `foobar' still in working directory
          cvs server: 1 file exists; remove it first

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Parce que ...

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Oui, enfin en fait c'est tout simplement comme ça que ça devrait être, je ne comprends pas en quoi svn devrait effacer lui-même un fichier local...

          • [^] # Re: Parce que ...

            Posté par  (site web personnel) . Évalué à 7.

            Oui, mais si je me souviens bien "cvs rm -f fichier" le supprime aussi localement.
            Un peu comme svn rm --force, quoi...

          • [^] # Re: Parce que ...

            Posté par  (site web personnel) . Évalué à 4.

            maintenant, si tu vais cvs remove -f foobar, il fait la même chose que svn dans le cas de Fabien... au moment du commit si je ne m'abuse (sauf si le fichier est Locally Modifed, dans ce cas il refusera de le supprimer)

            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  . Évalué à 9.

              > 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?

              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  . Évalué à 10.

        > 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.

        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  (site web personnel) . Évalué à 4.

    http://plan9.bell-labs.com/magic/man2html/4/fossil(...)
    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  (site web personnel) . Évalué à 4.

    1. C'est justement parce que l'on est plus en 1998 que l'on ne peut plus récupérer un fichier effacé : le système est trop dynamique, il y a trop de processus, les blocs libres peuvent être repris à la première activité. Le déseffacement, ça n'a marché que sur les machines monotaches, avec ce bon vieil MS-DOS.

    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  (site web personnel, Mastodon) . Évalué à 3.

      En fait on ne peut plus faire ce qu'on faisait avant, parce que maintenant c'est plus compliqué ? La raison me fait doucement sourire quand même, je penserai à la ressortir quand on me demandera de développer un truc qui existait avant "euh non on ne peut plus, tu comprends maintenant c'est compliqué les choses..."

    • [^] # Re: Réponses

      Posté par  (site web personnel) . Évalué à 6.

      Ca c'est une mauvaise raison. Si ce n'est pas possible de récupérer un fichier effacé ce n'est pas à cause du multitache, c'est surtout parce que le système ne le prévoit pas. Il serait tout à fait possible pour un FS d'essayer de ne pas réutiliser tout de suite les blocs fraichement libérés. Il serait aussi possible de déplacer les fichiers dans un répertoire type "poubelle" comme Windows. Il serait aussi possible de simplement les marquer comme effacés et ne réellement les effacer que quand on fait un expunge comme sous IMAP. Il serait aussi possible ... de plein de choses.
      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  (site web personnel, Mastodon) . Évalué à 1.

        Et oui, maintenant que le système devient un peu plus grand publique ça commence à être un manque.

        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  (site web personnel) . Évalué à 5.

          FAT32 bordel, FAT32, rien de tel pour récupérer des fichiers effacés par mégarde ;-)

          • [^] # Re: Réponses

            Posté par  . Évalué à 5.

            Rien de tel pour en perdre aussi.

            • [^] # Re: Réponses

              Posté par  (site web personnel) . Évalué à 3.

              moi, je voudrais saluer un crash de FS sous windows qui m'as planté toute mon arborescence CVS... J'comprends pas, je peux pas non plus récupérer les fichiers !
              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  (site web personnel, Mastodon) . Évalué à -5.

    trop gros !!! passeras pas !

    M.

  • # DragonFly BSD

    Posté par  . Évalué à 6.

    Matt Dillon, le leader du projet DragonFly BSD, est justement en train d'inclure une couche de journalisation, qui permettra à terme, et entre autres, d'annuler les modifications apportées à un FS.

    cf. http://leaf.dragonflybsd.org/mailarchive/kernel/2005-03/msg00038.html

    • [^] # Re: DragonFly BSD

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      C'est le genre de choses auxquelle je penserais. Evidemment que ça prend de la place, mais je m'en fous on a des disques énormes désormais, et libre à moi de limiter le backrool sur X opérations par exemple, suivant la taille de mon disque.

    • [^] # Re: DragonFly BSD

      Posté par  (site web personnel) . Évalué à 4.

      Tiens donc, Matt Dillon. Cela faisait bien longtemps que je n'avais pas vu ce nom. Ah, le bon temps quand je passais des nuits à faire tenir un workbench minimaliste et Dice C réduit un max sur 1 disquette bootable et le RAM disk de mon Amiga...

      Pfiou. Nostalgie quand tu nous tiens.

  • # Rien n'est perdu !

    Posté par  . Évalué à 10.

    Effectivement, un svn rm supprime les fichiers en local et dans la version courante (HEAD) du référentiel Subversion.

    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  (site web personnel, Mastodon) . Évalué à 3.

      Evidemment qu'on peut récuperer des fichiers effacés dans un repository, depuis longtemps. Mais est-ce qu'on peut récupérer des fichiers effacés qu'on a ajouté sans commiter ? A ce que j'en vois, c'est non.

      Est-ce que je me trompe ?

  • # Filesystem "versionalisé" ? (!$@ de subversion) : c possible

    Posté par  (site web personnel) . Évalué à 2.

    2. Pourquoi je n'ai toujours pas de système de fichier journalisé en interne pour pouvoir revenir à des versions ultérieures ???

    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  (site web personnel, Mastodon) . Évalué à 3.

      Enfin XML pour ce genre de choses... Moi toutes les experiences que j'ai avec XML (je l'utilise régulièrement pour la sauvegarde d'informations) c'est que ça rame, même en utilisant du SAX avec des patterns qu'il faut pour que ce soit fait proprement.

      • [^] # Re: Filesystem "versionalisé" ? (!$@ de subversion) : c possible

        Posté par  (site web personnel) . Évalué à 2.

        Tiens je tout pareil ! J'utilise rexml pour travailler sur du XML depuis ruby, et quand ils disent "It is reasonably fast" ça me fait bien rire...

        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  (site web personnel, Mastodon) . Évalué à 10.

      qui se posent la question, c'est un système de versionning qui sera entièrement basé sur du xml et ses technologies

      Quand tu as un problème informatique, il y a toujours une bonne âme pour te suggerer XML. Tu as maintenant 2 problèmes.

  • # Tu as oublié la question 3

    Posté par  . Évalué à 2.

    "3. Pourquoi je ne fais pas de sauvegardes ?"

  • # bien trouvé !

    Posté par  . É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)

  • # svn

    Posté par  . Évalué à 2.

    > 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 ... »

    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  (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  . Évalué à 0.

        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...

        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  (site web personnel) . Évalué à 2.

          > avec un niveau du genre "major" ou "critical"

          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  . Évalué à 2.

            mais certainement pas avec un niveau critique qui est normalement réservé aux bugs à cause desquels le logiciel failli totalement à sa mission

            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  (site web personnel) . Évalué à 2.

              Ben voyons, dans le journal même il a été annoncé avoir eu comme réponse are you sure et il balance un --force ; mais à part ça le logiciel ne l'a pas annoncé clairement hein.

              En tout cas moi je n'utilise pas l'informatique pour faire de la mauvaise foi.

              • [^] # Re: svn

                Posté par  (site web personnel, Mastodon) . Évalué à -1. 

                $ svn remove toto
svn: Use --force to override this restriction
svn: 'toto' has local modifications
                Tu le trouves clair toi ce !$@ de message ? Bah pas moi, enfin c'est normal, faut dire que je commence l'informatique. Dans j'aurai un minimum d'experience ça devrait aller mieux.

                • [^] # Re: svn

                  Posté par  (site web personnel) . Évalué à 7.

                  Bon, c'est vraiment la dernière fois :
                  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  . Évalué à 2.

                  Moi je suis d'accord. Je vais envoyer un patch qui demande "Are you really sure" si tu utilise "--force". Deux fois.

      • [^] # Re: svn

        Posté par  . Évalué à 1.

        > svn: 'toto' has local modifications

        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  . Évalué à 3.

          $ svn help rm
          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  (site web personnel) . Évalué à 2.

    C'est le genre de choses qui est relativement facile a faire avec un translator sur le Hurd. Ca presente aussi l'avantage que tu peux decider quels repertoires journaliser en tant qu'utilisateur (par rapport a un systeme de fichier journalise, qui est une solution bien plus lourde, puis qu'il faut prevoir a l'avance quel partition fera quelle taille etc).

    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  . Évalué à 5.

    Hm, je detecte une petite dose de mauvaise fois quand meme... (et encore je dis pas grande pour pas être méchant, pcq ca va chier dans la suite de mon message :D ).

    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  . Évalué à -1.

      > Je conclurais de la façon suivante. - Amis developpeurs d'outils foutez tous des warnings bien puissants à chaque destruction d'octet

      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  (site web personnel) . Évalué à 1.

        Je crois qu'il faisait de l'ironie. :-)

        • [^] # Re: Petite dose de mauvaise fois

          Posté par  (site web personnel) . Évalué à -1.

          Je crois qu'il faisait de l'ironie. :-)

          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.

  • # INotify

    Posté par  (site web personnel) . Évalué à 1.

    Ca doit être faisable avec un kernel inotify, un peu à la beagle

    • [^] # Re: INotify

      Posté par  (site web personnel) . Évalué à 2.

      Ou bien avec FUSE (ou lufs ou v9fs ou...).

      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  . Évalué à 2.

        Ca fait plusieurs fois que je te vois poster sur v9fs...

        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  (site web personnel) . Évalué à 2.

          Ca m'étonnerait que j'ai déjà parlé de v9fs, j'en ai pris connaissance il y a à peine quelques heures. Par contre j'ai peut-être déjà parlé de Plan9 (dont j'ai commencé à comprendre l'intérêt au FOSDEM de cette année [0]). Je n'utilise ni l'un ni l'autre. Le liveCD Plan9 refuse de booter sur ma machine et j'ai pas vraiment l'usage de v9fs pour le moment mais je trouve qu'il y a des idées intéressantes.

          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  . Évalué à 1.

    Je crois pas avoir vu de commentaire le disant, donc au cas où ça intéresse qqun, c'est l'option revert qu'il aurait fallu utiliser. Ça aurait supprimer le flag 'add' mais pas le fichier.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.