Et autant sur des sujets consensuels qui sont au coeur de "encyclopédies" classiques, Wikipédia n'a visiblement rien à redire (encore que ceux qui se prévalent desdites études sont les premiers à dire qu'une seule n'en fait pas une "souce fiable") autant sur des sujets plus pointus ça pêche parfois. Même si l'on comprend que les autres encyclopédies ne couvrent même pas ces sujets, parfois on aimerait un peu plus de densité et de confiance.
A l'occasion j'y jetterai un coup d'oeil. Je me souviens de ce projet d'encyclopédie lancé par Google et basé sur la "méritocratie" (un seul auteur, approuvé par ses relecteurs) et non sur la rédaction collective et la modération. Quelqu'un se souvient du nom ?
Ce fut un cuisant échec, mais les idées n'étaient toutes mauvaises quand on voit les querelles de chapelles qu'on trouve sur Wikipédia.
C'est codé en objective C ? Vraiment ?
Dans mes souvenirs c'était du python.
Vous passez bientôt à Swift ? Ok je sors.
(Au passage un petit bug: Dans le calendrier on doit pouvoir modifier la plage d'un rdv puisque le curseur change d'aspect, mais ça le déplace au lieu de ça. Chrome sous Windows)
Ma réflexion ne portait pas sur le fait que git communique ou non avec les autres dépôts qu'au travers des synchronisations. Je sais que les commandes dont tu parles existent mais elles n'ont pas la même finalité.
Ma remarque portait plutôt sur le fait que certains pensent que le hg incoming est un plus par rapport à Git alors qu'en fait cette commande vient juste pour rendre cohérente la conception de Hg.
Hg n'intègre pas de part sa conception, le fait de séparer la synchronisation des dépôts de l'intégration avec son code (merge).
Ceci à l'avantage de la simplicité dans certains cas mais peut s'avérer plus contraignants dans d'autres. Du coup cette commande pour inspecter les commits du dépôt distant est indispensable pour le bon fonctionnement de hg alors qu'elle ne l'est pas pour Git.
A l'inverse, le modèle de git est plus complexe à maîtriser. Combien de nouveaux venus sur Git qui ne comprennent pas la différence entre un git pull et un git fetch merge|rebase réclament cette commande ou sont rassurés de pouvoir browser le serveur avant de se synchroniser.
Avec git, tu fetches sa branche et tu utilises tous les outils à ta disposition pour faire ta comparaison, checkout y compris (build, …). et tu n'intègres que si tu le souhaites avant de pusher sur le "serveur". Tu peux laisser le soin de l'intégration à un autre et tu peux vérifier et communiquer sur vos changements respectifs (CI) sans pollution.
Avec hg, soit tu en passes par ta technique, comme un palliatif pour communiquer. Soit tu pulles et tu te retrouves avec 2 heads à résoudre, forcé à intégrer, si le serveur oblige à n'avoir qu'une seule head pour pouvoir lancer la CI.
C'est pour ça que beaucoup finissent par utiliser les plugins qui adoptent le comportement à la git, je pense.
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'est qu'avec hg cette possibilité est indispensable car dès que l'on pull en récupère immanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark). Une branche hg est plutôt un "flux" de développement qui à un moment donné, fait qu'on a plusieurs version concurrentes (plusieurs têtes en même temps) du même flux. un dépôt git, n'a qu'une référence pour une branche à tout moment (d'où les précautions avec le -force qui peut déplacer une tête et perdre de l'historique).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'ets qu'avec hg cette posdibilité est indispensable car dès que l'on pull en récupère inmmanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
C'est çà 3 mois sans bouffer quand tu es u ouvrier au SMIC et tout au bon vouloir de l'administration. L'arbitraire complet.
Et on ne parlera même pas du montant de l'indemnité.
CQFD.
Et je maintiens: tu dis de la merde et je le formulerais autrement si tu étais plus respectueux de tes contradicteurs.
Le constat est le suivant: si je décide de démissionner alors que j'ai cotisé 10 ans, je ne touche absolument rien sauf
à ce que mon patron soit d'accord pour une rupture à l'amiable ou que je rentre dans les clauses dérogatoires que tu cites (lisez-les pour vous marrer un peu).
Je n'ai donc aucune liberté de choisir et comme l'assurance chômage est obligatoire et n'est pas soumise à la concurrence, je ne peux pas en contracter une autre plus favorable à la place (sauf à ce que j'en prenne une en plus si j'ai les moyens).
Comme toi, je souhaite que ceci soit privatisé pour laisser la liberté à chacun de choisir l"assurance qui le représentera et là, un équilibre se rétablirait.
Le patronnat sait très bien que ceci est un moyen de pression et les affaires de rupture pour faute grave (lorsque ta clause de mobilité entre en jeu à l'autre bout de la France ou en Roumanie pour te faire craquer) sont légions. A l'inverse un employeur qui veut se faire la belle a intérêt à avoir un plan de rechange et bien souvent faire confiance au futur employeur qu'il ne le plante pas pendant le préavis.
Au fait tu lui reproches quoi au CDI exactement ?
Parce que des possibilité pour licencier un CDI il y en a pléthore.
Le jour ou celui qui choisira de démissionner sans l'accord de son patron ne sera pas tenu de crever de faim sans toucher le chômage alors qu'il a cotisé comme les autres. Bizarrement cette flexibilité là, le patron n'en veut pas.
Par contre, il voudrait bien pouvoir se délester sans contrainte et continuer de se gaver de subventions.
Et là le licenciement économique et là pour éviter les abus mais il existe bel et bien.
S'il devait y avoir un contrat unique pourquoi s'aligner sur le CDD et pas le CDI ?
On verrait si les artisans (le premier employeur de France parait-il) delocalisent …
Entre soulager un bourgeois d'une partie de sa fortune qu'il ne doit qu'à ses rentes ou à l'héritage colonial du passé et rétablir la ségrégation raciale …
Quand les libéraux mettent sur le même pied les 2 extrêmes, ils ne sont juste pas crédibles.
Posté par El Titi .
En réponse à la dépêche Fim 1.1.0.
Évalué à 3.
J'ai déjà eu l'occasion de tester ce soft pour mon propre cas d'utilisation que je décris :
Gérer un catalogue de fichiers qui garde une trace des fichiers que j'ai déjà utilisés et volontairement effacés.
Par exemple, si j'ai déjà visionné un podcast que j'ai mis de coté et que je le récupère à nouveau, je veux que le produit me le signale. S'il est nouveau, je veux qu'il l'insère et si c'est un doublon qu'il le ne rajoute pas au catalogue.
De part sa conception qui s'appuie sur l'historique, il permet de visualiser chaque différence mais ne permet pas de comparer de manière agrégée au catalogue entier (englobant les déjà vu), je n'y suis pas parvenu. Je n'ai pas besoins des états intermédiaire mais bien de pouvoir compare à tout mon catalogue présent et passé.
Du coup j'ai du mal à saisir l'intérêt.
Pour checker l'intégrité de fichier Ok (encore que pas besoin d'historique) mais
si c'est pour pouvoir gérer des gros fichiers avec Git, il vaut mieux se tourner vers un projet qui est soutenu par des grands du domaine (Github et Atlassian), qui ont uni leur force pour initier le projet suivant https://github.com/github/git-lfs
Au moins ça reste compatible de base avec Git et on bénficie de toute la tuyauterie associée, non ?
Du coup, il faut rajouter la ligne suivante dans la procédure d'install:
brew install coreutils
et editer le shell fim en remplaçant par greadline.
Il doit y avoir une autre solution plus propre (fournir une autre shell pour mac ou jouer avec le path et un symlink, …) mais je ne suis pas assez fortiche pour faire des recommandations.
J'ai testé sur un de mes dirs et ça marche nickel.
Les release sont simplement des zips de commits taggés, non ?
A la limite on peut rajouter de checkouter le dernier tag stable.
Sinon je peux aussi tester avec un de tes bundles et modifier la procédure.
PS: Inutile de mettre mon nom, c'est gentil, mais je ne te réclamerai pas de droits d'auteurs (Tu ne t'en sortiras jamais sinon). Si tu ne veux pas apposer ta propre garantie, mets simplement que c'est testé par des contributeurs.
Merci pour la réponse.
De ce tableau, j'en déduis que MD5 est plus sujet aux collisions et assez médiocre question performance. Je suis surpris mais c'est rassurant.
Autre question.: Si "purge" supprime les états antérieurs, ça signifie qu'il va perdre l'information comme quoi un fichier a été supprimé par le passé, alors que c'est ce qui est intéressant dans mon cas d'utilisation. Je n'ai toujours pas bien saisi ce qu'apportait par rapport à tes besoins une vision intermédiaire de chaque plutôt que globale en agrégeant tout.
Pour le hash de 1mb, lorsque je demandais si ça pouvait suffire, c'est par rapport au fait de différencier des fichiers, pas par rapport aux performances. C'est pour ça que je parlais de blocs séparés.
Pour ce qui concerne les contributions, je soumettrai peut-être quelques feature requests/bugs en fonction de l'usage. Pour le code j'ai jeté un coup d'oeil et c'est plus tôt pas mal (mis à part les commentaires assez chiches ;-). J'arrive presque à comprendre . Java n'est pas trop ma tasse de thé (trop verbeux) mais qui sait ? Accepterais-tu des contributions en Groovy ?
Sinon, j'avais oublié de te dire que le répertoire caché qu'on recopie ou déplace en conservant des chemins relatifs (inspiré des VCS) est astucieux aussi. Mon script conservait une base centralisée qui essayait de tracer les fichiers sur tous les disques montés et en restant indépendant des machines. Du coup j'essayais de conserver un chemin absolu qui concatenait le nom de volume (en NTFS) et le chemin depuis la racine. Mais c'était un vrai casse-tête surtout pour traiter les autres fs. Il faut vraiment que je l'utilise sur mes médias pour te faire un retour complet.
[^] # Re: Ça fait 15 ans que les vraies encyclopédies sont décédées
Posté par El Titi . En réponse à la dépêche Wikipédia a soufflé ses 15 bougies. Évalué à 2.
Merci,
Ca m'a permis de découvrir Citizendium qui a vocation rendre le contenu "spécialisé" plus fiable https://fr.wikipedia.org/wiki/Citizendium.
Et autant sur des sujets consensuels qui sont au coeur de "encyclopédies" classiques, Wikipédia n'a visiblement rien à redire (encore que ceux qui se prévalent desdites études sont les premiers à dire qu'une seule n'en fait pas une "souce fiable") autant sur des sujets plus pointus ça pêche parfois. Même si l'on comprend que les autres encyclopédies ne couvrent même pas ces sujets, parfois on aimerait un peu plus de densité et de confiance.
A l'occasion j'y jetterai un coup d'oeil. Je me souviens de ce projet d'encyclopédie lancé par Google et basé sur la "méritocratie" (un seul auteur, approuvé par ses relecteurs) et non sur la rédaction collective et la modération. Quelqu'un se souvient du nom ?
Ce fut un cuisant échec, mais les idées n'étaient toutes mauvaises quand on voit les querelles de chapelles qu'on trouve sur Wikipédia.
# Langage
Posté par El Titi . En réponse à la dépêche Sortie de la version 3 de SOGo. Évalué à 1. Dernière modification le 01 février 2016 à 18:38.
C'est codé en objective C ? Vraiment ?
Dans mes souvenirs c'était du python.
Vous passez bientôt à Swift ? Ok je sors.
(Au passage un petit bug: Dans le calendrier on doit pouvoir modifier la plage d'un rdv puisque le curseur change d'aspect, mais ça le déplace au lieu de ça. Chrome sous Windows)
[^] # Re: typescript ?
Posté par El Titi . En réponse à la dépêche Superpowers sort en libre/opensource. Évalué à 3.
Et accessoirement, la version 2 du framework à la mode de Google, Angular, s'appuie dessus.
[^] # Re: C'est le codage en virgule flottante
Posté par El Titi . En réponse au message Euh… comment dire… C'est bizarre.. Évalué à 2.
Ou plutôt elle arrondit.
Peut-être en effet.
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.
Merci pour ces éclaircissements.
Ma réflexion ne portait pas sur le fait que git communique ou non avec les autres dépôts qu'au travers des synchronisations. Je sais que les commandes dont tu parles existent mais elles n'ont pas la même finalité.
Ma remarque portait plutôt sur le fait que certains pensent que le hg incoming est un plus par rapport à Git alors qu'en fait cette commande vient juste pour rendre cohérente la conception de Hg.
Hg n'intègre pas de part sa conception, le fait de séparer la synchronisation des dépôts de l'intégration avec son code (merge).
Ceci à l'avantage de la simplicité dans certains cas mais peut s'avérer plus contraignants dans d'autres. Du coup cette commande pour inspecter les commits du dépôt distant est indispensable pour le bon fonctionnement de hg alors qu'elle ne l'est pas pour Git.
A l'inverse, le modèle de git est plus complexe à maîtriser. Combien de nouveaux venus sur Git qui ne comprennent pas la différence entre un git pull et un git fetch merge|rebase réclament cette commande ou sont rassurés de pouvoir browser le serveur avant de se synchroniser.
Une partie de la complexité de Git provient aussi du fait que ce qui est implicite pour Hg a dû faire l'objet de
beaucoup de contorsions et de balbutiements pour automatiser de manière acceptable le pull et faire le match entre l'upstream et le local alors que pour Hg … c'est juste la même branche.
En témoigne par exemple les évolutions successives sur les set-upstream, la config des refspecs et plein d'autres paramètres qu'il faut bien souvent tuner. Ou comment les git users se transforment en bookmarkeurs de Stackoverflow compulsifs:
http://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-upstream-all-the-time
http://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch
…
[^] # Re: C'est le codage en virgule flottante
Posté par El Titi . En réponse au message Euh… comment dire… C'est bizarre.. Évalué à 3.
Mais pourquoi la calculatrice windows donne le bon résultat dans ce cas ?
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 6.
Ca montre bien les limites du modèle.
Avec git, tu fetches sa branche et tu utilises tous les outils à ta disposition pour faire ta comparaison, checkout y compris (build, …). et tu n'intègres que si tu le souhaites avant de pusher sur le "serveur". Tu peux laisser le soin de l'intégration à un autre et tu peux vérifier et communiquer sur vos changements respectifs (CI) sans pollution.
Avec hg, soit tu en passes par ta technique, comme un palliatif pour communiquer. Soit tu pulles et tu te retrouves avec 2 heads à résoudre, forcé à intégrer, si le serveur oblige à n'avoir qu'une seule head pour pouvoir lancer la CI.
C'est pour ça que beaucoup finissent par utiliser les plugins qui adoptent le comportement à la git, je pense.
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.
Je reposte puisque je ne peux pas "passer":
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'est qu'avec hg cette possibilité est indispensable car dès que l'on pull en récupère immanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark). Une branche hg est plutôt un "flux" de développement qui à un moment donné, fait qu'on a plusieurs version concurrentes (plusieurs têtes en même temps) du même flux. un dépôt git, n'a qu'une référence pour une branche à tout moment (d'où les précautions avec le -force qui peut déplacer une tête et perdre de l'historique).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
[^] # Re: Popularité
Posté par El Titi . En réponse au journal Matt Mackall, l'auteur de Mercurial, passe la main. Évalué à 3.
Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.
hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.
Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
Ce que je comprends c'ets qu'avec hg cette posdibilité est indispensable car dès que l'on pull en récupère inmmanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark).
Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.
[^] # Re: Dropbox
Posté par El Titi . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2.
Ici on ne parle que de solutions basées sur des fichiers encryptés. Existe-il une appli libre comme 1Password que l'on puisse auto-héberger ?
[^] # Re: métriques
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 5. Dernière modification le 14 janvier 2016 à 11:18.
C'est çà 3 mois sans bouffer quand tu es u ouvrier au SMIC et tout au bon vouloir de l'administration. L'arbitraire complet.
Et on ne parlera même pas du montant de l'indemnité.
CQFD.
Et je maintiens: tu dis de la merde et je le formulerais autrement si tu étais plus respectueux de tes contradicteurs.
[^] # Re: métriques
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 3.
En quoi c'est faux ?
Le constat est le suivant: si je décide de démissionner alors que j'ai cotisé 10 ans, je ne touche absolument rien sauf
à ce que mon patron soit d'accord pour une rupture à l'amiable ou que je rentre dans les clauses dérogatoires que tu cites (lisez-les pour vous marrer un peu).
Je n'ai donc aucune liberté de choisir et comme l'assurance chômage est obligatoire et n'est pas soumise à la concurrence, je ne peux pas en contracter une autre plus favorable à la place (sauf à ce que j'en prenne une en plus si j'ai les moyens).
Comme toi, je souhaite que ceci soit privatisé pour laisser la liberté à chacun de choisir l"assurance qui le représentera et là, un équilibre se rétablirait.
Le patronnat sait très bien que ceci est un moyen de pression et les affaires de rupture pour faute grave (lorsque ta clause de mobilité entre en jeu à l'autre bout de la France ou en Roumanie pour te faire craquer) sont légions. A l'inverse un employeur qui veut se faire la belle a intérêt à avoir un plan de rechange et bien souvent faire confiance au futur employeur qu'il ne le plante pas pendant le préavis.
Quand au fait que ceci ne concerne pas le patronnat, c'est bizarre de constater qu'il fasse des propositions pour la réformer dans ce cas. qu'il se la boucle et laisse les salariés décider entre eux alors. Bizarre qu'ils n'en fassent pas pour privatiser.
http://www.lesechos.fr/12/02/2014/lesechos.fr/0203311492255_assurance-chomage---les-propositions-chocs-du-medef.htm
Bref tu dis de la merde et tes airs méprisants ne trompent plus personne ici. Alors retourne à la technique si ca te chante pour redorer ton blason.
# Un petit mot de la fin
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 7.
Avec ce joli débat personne n'a encore osé la faire alors je me dévoue.
La conclusion de tout ça c'est que: "Persona non grata"
Ok je connais le chemin ----> []
[^] # Re: métriques
Posté par El Titi . En réponse au journal Persona, c'est bientôt la fin.. Évalué à 6.
Très fort l'amalgame CDI/fonctionnaire.
Au fait tu lui reproches quoi au CDI exactement ?
Parce que des possibilité pour licencier un CDI il y en a pléthore.
Le jour ou celui qui choisira de démissionner sans l'accord de son patron ne sera pas tenu de crever de faim sans toucher le chômage alors qu'il a cotisé comme les autres. Bizarrement cette flexibilité là, le patron n'en veut pas.
Par contre, il voudrait bien pouvoir se délester sans contrainte et continuer de se gaver de subventions.
Et là le licenciement économique et là pour éviter les abus mais il existe bel et bien.
S'il devait y avoir un contrat unique pourquoi s'aligner sur le CDD et pas le CDI ?
On verrait si les artisans (le premier employeur de France parait-il) delocalisent …
[^] # Re: Fatigant
Posté par El Titi . En réponse au journal Notepad++ et FN ; ou quand un développeur parle d'autre chose que de développement. Évalué à 10.
Entre soulager un bourgeois d'une partie de sa fortune qu'il ne doit qu'à ses rentes ou à l'héritage colonial du passé et rétablir la ségrégation raciale …
Quand les libéraux mettent sur le même pied les 2 extrêmes, ils ne sont juste pas crédibles.
[^] # Re: This is javaaa
Posté par El Titi . En réponse à la dépêche Fim 1.1.0. Évalué à 3. Dernière modification le 04 novembre 2015 à 10:47.
Au fait, tu peux me donner un equivalent de Minecraft écrit en PHP ?
Ok Merci. CQFD
[^] # Re: This is javaaa
Posté par El Titi . En réponse à la dépêche Fim 1.1.0. Évalué à 8.
Alors,
pour Python
https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html
PHP
https://www.cvedetails.com/google-search-results.php?q=php&sa=Search
Anéfé ca sent les arguments très fondés.
Bon on evitera de parler du GIL de cPython coté scalability, des features désactivées chez les hébergeurs de PHP qui sont juste des trous béants …
Quitte a faire le le troll de compet
[^] # Re: Il existe aussi Git-Annex
Posté par El Titi . En réponse à la dépêche Fim 1.1.0. Évalué à 3.
J'ai déjà eu l'occasion de tester ce soft pour mon propre cas d'utilisation que je décris :
Gérer un catalogue de fichiers qui garde une trace des fichiers que j'ai déjà utilisés et volontairement effacés.
Par exemple, si j'ai déjà visionné un podcast que j'ai mis de coté et que je le récupère à nouveau, je veux que le produit me le signale. S'il est nouveau, je veux qu'il l'insère et si c'est un doublon qu'il le ne rajoute pas au catalogue.
De part sa conception qui s'appuie sur l'historique, il permet de visualiser chaque différence mais ne permet pas de comparer de manière agrégée au catalogue entier (englobant les déjà vu), je n'y suis pas parvenu. Je n'ai pas besoins des états intermédiaire mais bien de pouvoir compare à tout mon catalogue présent et passé.
Du coup j'ai du mal à saisir l'intérêt.
Pour checker l'intégrité de fichier Ok (encore que pas besoin d'historique) mais
si c'est pour pouvoir gérer des gros fichiers avec Git, il vaut mieux se tourner vers un projet qui est soutenu par des grands du domaine (Github et Atlassian), qui ont uni leur force pour initier le projet suivant https://github.com/github/git-lfs
Au moins ça reste compatible de base avec Git et on bénficie de toute la tuyauterie associée, non ?
Plus d'info ici:
http://www.infoq.com/news/2015/04/github-large-file-storage
```
git lfs track "*.pdf"
git add file.pdf
git commit -m "Add design file"
git push origin master
[^] # Re: ouais ouais ouais
Posté par El Titi . En réponse au journal [HS] Marguerite, le film. Évalué à 2.
Pour Catherine Frot, je te laisse à ton appréciation après ne pas avoir terminé ce navet:
Imogene
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
C'est fait. Un ticket est ouvert.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
Inutile, j'ai trouvé d'où venait le problème. Sous Mac readlink version Gnu n'est pas la version par défaut: Il faut donc installer coreutils
C'est expliqué ici:
http://stackoverflow.com/questions/1055671/how-can-i-get-the-behavior-of-gnus-readlink-f-on-a-mac
Du coup, il faut rajouter la ligne suivante dans la procédure d'install:
et editer le shell fim en remplaçant par greadline.
Il doit y avoir une autre solution plus propre (fournir une autre shell pour mac ou jouer avec le path et un symlink, …) mais je ne suis pas assez fortiche pour faire des recommandations.
J'ai testé sur un de mes dirs et ça marche nickel.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2. Dernière modification le 11 septembre 2015 à 23:45.
Sinon je peux t'ouvrir un ticket mais chaque à commande que j'invoque, j'ai toujours de message au début,même si ça fonctionne:
Si j'ai du temps j'essaierai de déboguer sous Eclipse.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
Les release sont simplement des zips de commits taggés, non ?
A la limite on peut rajouter de checkouter le dernier tag stable.
Sinon je peux aussi tester avec un de tes bundles et modifier la procédure.
PS: Inutile de mettre mon nom, c'est gentil, mais je ne te réclamerai pas de droits d'auteurs (Tu ne t'en sortiras jamais sinon). Si tu ne veux pas apposer ta propre garantie, mets simplement que c'est testé par des contributeurs.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 2.
Merci pour la réponse.
De ce tableau, j'en déduis que MD5 est plus sujet aux collisions et assez médiocre question performance. Je suis surpris mais c'est rassurant.
Autre question.: Si "purge" supprime les états antérieurs, ça signifie qu'il va perdre l'information comme quoi un fichier a été supprimé par le passé, alors que c'est ce qui est intéressant dans mon cas d'utilisation. Je n'ai toujours pas bien saisi ce qu'apportait par rapport à tes besoins une vision intermédiaire de chaque plutôt que globale en agrégeant tout.
Pour le hash de 1mb, lorsque je demandais si ça pouvait suffire, c'est par rapport au fait de différencier des fichiers, pas par rapport aux performances. C'est pour ça que je parlais de blocs séparés.
Pour ce qui concerne les contributions, je soumettrai peut-être quelques feature requests/bugs en fonction de l'usage. Pour le code j'ai jeté un coup d'oeil et c'est plus tôt pas mal (mis à part les commentaires assez chiches ;-). J'arrive presque à comprendre . Java n'est pas trop ma tasse de thé (trop verbeux) mais qui sait ? Accepterais-tu des contributions en Groovy ?
Sinon, j'avais oublié de te dire que le répertoire caché qu'on recopie ou déplace en conservant des chemins relatifs (inspiré des VCS) est astucieux aussi. Mon script conservait une base centralisée qui essayait de tracer les fichiers sur tous les disques montés et en restant indépendant des machines. Du coup j'essayais de conserver un chemin absolu qui concatenait le nom de volume (en NTFS) et le chemin depuis la racine. Mais c'était un vrai casse-tête surtout pour traiter les autres fs. Il faut vraiment que je l'utilise sur mes médias pour te faire un retour complet.
[^] # Re: Trés beau projet.
Posté par El Titi . En réponse à la dépêche Sortie de Fim 1.0.2, qui vérifie l'intégrité de vos fichiers. Évalué à 3. Dernière modification le 11 septembre 2015 à 08:53.
Et sinon tu peux mettre à jour ton wiki, la procédure d'install fonctionne pour Mac: