« Mais si le fait est vrai, si la jeune femme ne s’est point trouvée vierge, on fera sortir la jeune femme à l’entrée de la maison de son père ; elle sera lapidée par les gens de la ville, et elle mourra […] Si l’on trouve un homme couché avec une femme mariée, ils mourront tous deux, l’homme qui a couché avec la femme, et la femme aussi […] Si une jeune fille vierge est fiancée, et qu’un homme la rencontre dans la ville et couche avec elle, vous les amènerez tous deux à la porte de la ville, vous les lapiderez, et ils mourront, la jeune fille pour n’avoir pas crié dans la ville, et l’homme pour avoir déshonoré la femme de son prochain. » Dt 22. 20-24
« Si un homme commet adultère avec une femme mariée, s’il commet adultère avec la femme de son prochain, l’homme et la femme adultère seront punis de mort. » Lv 20. 10
Ah oui l'Ancien testament, c'était la version1.0.
Tout a changé dans la 2.0.
Mais bon on doit trouver des allumés qui prennent ça au pied de la lettre comme il doit y avoir des interprétations différentes du Coran.
Après tout, c'est juste la version 3.0 de la Bible. Ils ont juste 700 ans de retard sur cette interprétation et je ne vous évoquerai pas à quoi ressemblait la chrétienté il y a 700 ans, glorieuse époque de l'Inquisition où les "sorcières" étaient brûlées vives pour moins que ça.
Souvent, les femmes ne savent pas ce que dit le Coran, car le texte est écrit en arabe, et dans beaucoup de pays non arabophones on déchiffre l'arabe sans comprendre le sens des versets...
Tu veux dire un peu comme le clergé catholique dont les prêtres lisaient la Bible et officiaient en latin que eux seuls comprenaient et qui n'ont commencé à démocratiser qu'à partir du moment où ils sentaient leur influence vaciller.
Mais, à 14 ans, je suis tombée sur un Coran traduit en bengali, et j'ai comparé plus de 12 traductions bengalies différentes... A ma grande surprise, j'ai compris que c'était bien Allah qui déclarait les femmes inférieures, qui prônait la polygamie, le divorce uniquement pour les hommes, le droit de battre leurs épouses, l'interdiction faite aux femmes de porter témoignage en justice, l'inégalité en matière d'héritage, le port du voile.
Quant au sexisme dans la Bible, on évitera d'en parler en partant de la genèse qui veut que enfante dans la douleur en rémission de son péché originel au nouveau testament que tu décris si bon:
" Vous qui craignez le Christ, soumettez-vous les uns aux autres ; femmes, soyez soumises à vos maris, comme au Seigneur. Car le mari est le chef de la femme, tout comme le Christ est le chef de l'Église, lui le Sauveur de son corps". Mais, comme l'Église est soumise au Christ, que les femmes soient soumises en tout à leurs maris " (Ep 5,22-24).
J'aimerais trouvé une configuration qui fasse que ceux qui ne l'utiliseront pas (genre ceux qui utilisent tortoisehg/hgtk) ait le meme comportement. Apparement, l'option force empeche de faire un merge, et new branch créé une branch si un merge est nécessaire.
C'est ca que je t'explique, c'est valable par défaut. (cf.ma sortie d'écran)
Le push est refusé et le resolve est fait dans ton clone (comme dans ton workspace SVN). Pourquoi créer une branche ?
Au contraire, le -force pushe une version concurrente (et le new branch créé une nouvelle branche qui pollue ton repo (c'est juste un nom sur ta revision en fait)
Si tu veux "vraiment" (mode paranoiaque) te prémunir contre le -f, il te suffit d'installer un hook coté serveur. http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_pu(...)
Mais je trouve ça tres stupide de ne pas avoir un fichier de conf qui se déploie lors d'un clone, comme git. Meme si ca ne déploi pas de hook qui peuvent etre dangeureux effectivement, je veux juste des options par défaut.
Tu dois pouvoir te débrouiller en ajoutant un .hgrc dans ton depôt et en faisant
un truc du genre %include $(hg root)/.hgrc dans ton fichier .hgrc par défaut (vaudrait mieux sécuriser le truc pour checker la provenance du clone)
Comme ça chaque projet centralise ses préférences.
Ca marche un peu comme les inclusions de makefile.
Par exemple, le --force est pour push (et non pas commit, dsl). Je dois faire "hg --force --new-branch" pour être sur que tout ce passe bien. Il y a un moyen de configure mon hgrc pour qu'il fasse ça tout seul automatiquement?
Je comprend toujours pas pourquoi tu veux forcer le push dans une nouvelle branche si tu veux un comportement à la SVN.
Dans SVN ton commit est refusé si quelqu'un d'autre a commité entretemps et tu dois résoudre avant de resoumettre. Ici par défaut sans --force ca fonctionne comme ca pour peu que tu aies positionné:
commit.autopush= hg push
J'utilise mercurialeclipse 1.7 (qui est donc postérieur à hgeclipse 1.5), et je n'ai pas de "compare with" pour les dossiers. Pour un fichier donné, effectivement, j'ai accès à ces options, mais ce que je veux, évidement, c'est un diff depuis la racine du projet (et pas uniquement fichier par fichier).
Là je ne peux pas te répondre, car je ne connais pas assez le plugin eclipse
mais la synchronisation view devrait suffire la plupart du temps non ? http://www.javaforge.com/wiki/76412#section-Synchronization+(...)
Au lieu de te donner l'arbo complète, tu browses le changeset de manière hiérarchique.
Une bonne âme qui passe par ici pourra peut-être t'aider (au hasard pff ?)
Pour le hgrc, ca ne devrait être le cas si tu le place dans ton profil Windows non ? http://www.selenic.com/mercurial/hgrc.5.html
Les hooks ne sont pas répliqués pour des raison de sécurité http://hgbook.red-bean.com/read/handling-repository-events-w(...)
Tu devrais y être habitué avec les triggers coté client de CC
Les solutions sont donc spécifiques à ta boite (montage NFS, scripts de synchro a démarrage, un .hgrc à récupérer sur un site, un packaging d'install customisé, ...)
Y'a pas de solution miracle.
L'avantage est que tu peux mettre aussi des hooks coté serveurs et il faut bien différencier ceux que tu veux déployer et ceux que tu veux sur ton repository central.
commit --force ???
Y'a pas d'option --force, tu peux toujours commiter dans ton clone
est ce qu'il est possible de renommer la branche principale ("default" => "mainline ou trunk") ?
Si je développe en local et qu'il y a un conflit, au lieu de me dire "il y a un conflit, faite un update + corriger le conflict", il me créé une branche sur le repository central et c'est au maintainer de merger les 2 branches. Je veux un fonctionnement sans maintainer au niveau du repository central...
Normalement il proteste quand tu essaies de pusher alors qu'il y aune autre head et te demande d'updater et merger. C'est ce que tu attends non ?
Moi j'ai bien un message:
"""
pushing to ..\repo1
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
"""
Sinon, quel est ton problème avec la création de branche ?
Quel message lors du push ?
Si tu crées une branche, il faut la créer une fois et la pusher.
Il faut pas la recréer sur le clone distant.
Lorsque tu dis que tu as laissé tombé le plugin poussif tu parles de celui de Hg "achement mieux gaulé" que celui de git.
Tu peux préciser (on envisage un passage sous Hg au taf).
Toutafé, mais il était seul et IBM a commencé par VA pour Smalltalk puis C++ puis après Java.
En revanche, le profiler de C++ était une rolls, il m'a sauvé la mise plus d'une fois.
Au départ on avait Netbeans, l'ide de Borland et IntelliJ.
IBM a compris qu'il étaient à la ramasse, ont libéré le core et ca a tué la concurrence.
Sun a libéré Netbeans après coup et la sauce n'a jamais pris.
IntelliJ a libéré aussi son core depuis et la division IDE de Borland est morte.
Si j'essaie de comprendre, ca ressemble à la gestion par composant.
i.e que tu définis des articles de configuration qui ne sont pas de simples fichiers et qui obéissent à leur propre cycle de vie.
C'est le pendant coté GCL de l'architecture à base de composants http://en.wikipedia.org/wiki/Component-based_software_engine(...)
Ton application est un simple assemblage de plusieurs versions de composants.
Un composant peut être réutilisable dans plusieurs projets différents, modifiable ou non dans le projet.
On est soit fournisseur, soit consommateur du composant.
Si c'est un composant binaire et que tu es consumer et que tu n'a pas besoin de faire évoluer les sources tu t'en sors avec des outils comme Maven et un VCS est superflu sinon c'est utile.
UCM et Clearcase gère ça pas trop mal.
SVN le fait grâce au svn copy ("cheap copies") et aux svn:externals
Avec mercurial il faut utiliser le submodules et il doit y avoir un équivalent sous Git.
[^] # Re: Je profite...
Posté par El Titi . En réponse au journal Analyse perso du deal Nokia/Microsoft. Évalué à 3.
avait deja mis en place quelqu'un pour faire derailler Gnome
Ah oui, tout comme pour DLFP a son cheval de Troie.
T'as déjà pensé à consulter ?
[^] # Re: Émotion
Posté par El Titi . En réponse au journal palindrome. Évalué à 3.
[^] # Re: dois je
Posté par El Titi . En réponse au journal Recherche d'images sous licence libre. Évalué à 6.
DLFP n'oublie pas >:)
[^] # Re: C'est barbant!
Posté par El Titi . En réponse au journal rm mon amour. Évalué à 5.
[^] # C'est barbant!
Posté par El Titi . En réponse au journal rm mon amour. Évalué à 6.
[^] # Re: ca risque d'etre interessant
Posté par El Titi . En réponse à la dépêche Windows Phone 7 débarquera sur les Nokia. Évalué à 10.
[^] # Re: contribuer un dépôt ?
Posté par El Titi . En réponse à la dépêche Nuxeo propose son logiciel de gestion de dépôt documentaire open source à la fondation Eclipse. Évalué à 3.
http://www.infoq.com/news/2011/02/nuxeo-core
[^] # Re: contribuer un dépôt ?
Posté par El Titi . En réponse à la dépêche Nuxeo propose son logiciel de gestion de dépôt documentaire open source à la fondation Eclipse. Évalué à 5.
On l'a touché, le fond ? ;)
C'est DLFP, ici , le jour où le rapport signal bruit sera inversé Stallman se rasera.
[^] # Re: pour linux
Posté par El Titi . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 3.
[^] # Re: pour linux
Posté par El Titi . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 10.
dans l'application kivabien !
Tirer toutes les dépendances de KDE pour une simple appli ... quelle honte !
[^] # Re: rétrospective 2010
Posté par El Titi . En réponse à la dépêche Debian 6.0 Squeeze est sortie. Évalué à 0.
« Si un homme commet adultère avec une femme mariée, s’il commet adultère avec la femme de son prochain, l’homme et la femme adultère seront punis de mort. » Lv 20. 10
Ah oui l'Ancien testament, c'était la version1.0.
Tout a changé dans la 2.0.
Mais bon on doit trouver des allumés qui prennent ça au pied de la lettre comme il doit y avoir des interprétations différentes du Coran.
Après tout, c'est juste la version 3.0 de la Bible. Ils ont juste 700 ans de retard sur cette interprétation et je ne vous évoquerai pas à quoi ressemblait la chrétienté il y a 700 ans, glorieuse époque de l'Inquisition où les "sorcières" étaient brûlées vives pour moins que ça.
[^] # Re: rétrospective 2010
Posté par El Titi . En réponse à la dépêche Debian 6.0 Squeeze est sortie. Évalué à -1.
Souvent, les femmes ne savent pas ce que dit le Coran, car le texte est écrit en arabe, et dans beaucoup de pays non arabophones on déchiffre l'arabe sans comprendre le sens des versets...
Tu veux dire un peu comme le clergé catholique dont les prêtres lisaient la Bible et officiaient en latin que eux seuls comprenaient et qui n'ont commencé à démocratiser qu'à partir du moment où ils sentaient leur influence vaciller.
Mais, à 14 ans, je suis tombée sur un Coran traduit en bengali, et j'ai comparé plus de 12 traductions bengalies différentes... A ma grande surprise, j'ai compris que c'était bien Allah qui déclarait les femmes inférieures, qui prônait la polygamie, le divorce uniquement pour les hommes, le droit de battre leurs épouses, l'interdiction faite aux femmes de porter témoignage en justice, l'inégalité en matière d'héritage, le port du voile.
Quant au sexisme dans la Bible, on évitera d'en parler en partant de la genèse qui veut que enfante dans la douleur en rémission de son péché originel au nouveau testament que tu décris si bon:
" Vous qui craignez le Christ, soumettez-vous les uns aux autres ; femmes, soyez soumises à vos maris, comme au Seigneur. Car le mari est le chef de la femme, tout comme le Christ est le chef de l'Église, lui le Sauveur de son corps". Mais, comme l'Église est soumise au Christ, que les femmes soient soumises en tout à leurs maris " (Ep 5,22-24).
[^] # Re: Suite
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 2.
Pour la propagation des configs, voici un thread qui propose la même chose (celui qui est noté 2) avec les mêmes risques.
http://stackoverflow.com/questions/856523/version-controlled(...)
J'aimerais trouvé une configuration qui fasse que ceux qui ne l'utiliseront pas (genre ceux qui utilisent tortoisehg/hgtk) ait le meme comportement. Apparement, l'option force empeche de faire un merge, et new branch créé une branch si un merge est nécessaire.
C'est ca que je t'explique, c'est valable par défaut. (cf.ma sortie d'écran)
Le push est refusé et le resolve est fait dans ton clone (comme dans ton workspace SVN). Pourquoi créer une branche ?
Au contraire, le -force pushe une version concurrente (et le new branch créé une nouvelle branche qui pollue ton repo (c'est juste un nom sur ta revision en fait)
Si tu veux "vraiment" (mode paranoiaque) te prémunir contre le -f, il te suffit d'installer un hook coté serveur.
http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_pu(...)
[^] # Re: Suite
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 2.
Mais je trouve ça tres stupide de ne pas avoir un fichier de conf qui se déploie lors d'un clone, comme git. Meme si ca ne déploi pas de hook qui peuvent etre dangeureux effectivement, je veux juste des options par défaut.
Tu dois pouvoir te débrouiller en ajoutant un .hgrc dans ton depôt et en faisant
un truc du genre %include $(hg root)/.hgrc dans ton fichier .hgrc par défaut (vaudrait mieux sécuriser le truc pour checker la provenance du clone)
Comme ça chaque projet centralise ses préférences.
Ca marche un peu comme les inclusions de makefile.
Par exemple, le --force est pour push (et non pas commit, dsl). Je dois faire "hg --force --new-branch" pour être sur que tout ce passe bien. Il y a un moyen de configure mon hgrc pour qu'il fasse ça tout seul automatiquement?
Je comprend toujours pas pourquoi tu veux forcer le push dans une nouvelle branche si tu veux un comportement à la SVN.
Dans SVN ton commit est refusé si quelqu'un d'autre a commité entretemps et tu dois résoudre avant de resoumettre. Ici par défaut sans --force ca fonctionne comme ca pour peu que tu aies positionné:
commit.autopush= hg push
J'utilise mercurialeclipse 1.7 (qui est donc postérieur à hgeclipse 1.5), et je n'ai pas de "compare with" pour les dossiers. Pour un fichier donné, effectivement, j'ai accès à ces options, mais ce que je veux, évidement, c'est un diff depuis la racine du projet (et pas uniquement fichier par fichier).
Là je ne peux pas te répondre, car je ne connais pas assez le plugin eclipse
mais la synchronisation view devrait suffire la plupart du temps non ?
http://www.javaforge.com/wiki/76412#section-Synchronization+(...)
Au lieu de te donner l'arbo complète, tu browses le changeset de manière hiérarchique.
Une bonne âme qui passe par ici pourra peut-être t'aider (au hasard pff ?)
[^] # Re: Suite
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 2.
http://www.javaforge.com/project/HGE
L'history view te permet ça et le compare with previous existe depuis la 1.5
http://blogs.intland.com/main/entry/48
Pour le hgrc, ca ne devrait être le cas si tu le place dans ton profil Windows non ?
http://www.selenic.com/mercurial/hgrc.5.html
Les hooks ne sont pas répliqués pour des raison de sécurité
http://hgbook.red-bean.com/read/handling-repository-events-w(...)
Tu devrais y être habitué avec les triggers coté client de CC
Les solutions sont donc spécifiques à ta boite (montage NFS, scripts de synchro a démarrage, un .hgrc à récupérer sur un site, un packaging d'install customisé, ...)
Y'a pas de solution miracle.
L'avantage est que tu peux mettre aussi des hooks coté serveurs et il faut bien différencier ceux que tu veux déployer et ceux que tu veux sur ton repository central.
commit --force ???
Y'a pas d'option --force, tu peux toujours commiter dans ton clone
est ce qu'il est possible de renommer la branche principale ("default" => "mainline ou trunk") ?
Je crois pas mais je vois pas où est le pb.
[^] # Re: rétrospective 2010
Posté par El Titi . En réponse à la dépêche Debian 6.0 Squeeze est sortie. Évalué à 2.
Ce n'est pas la même chose que de dire 'les spongebobistes sont des cons qui n'ont rien compris à la vie'.
Pour revenir au sujet, que pensez-vous de debiannistes ?
[^] # Re: Les goûts et les couleurs…
Posté par El Titi . En réponse à la dépêche Debian 6.0 Squeeze est sortie. Évalué à 3.
[^] # Re: Suite
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 2.
Déjà quels hook utilises-tu, un truc comme ça ?
http://stackoverflow.com/questions/1235597/mercurial-automat(...)
Si je développe en local et qu'il y a un conflit, au lieu de me dire "il y a un conflit, faite un update + corriger le conflict", il me créé une branche sur le repository central et c'est au maintainer de merger les 2 branches. Je veux un fonctionnement sans maintainer au niveau du repository central...
Normalement il proteste quand tu essaies de pusher alors qu'il y aune autre head et te demande d'updater et merger. C'est ce que tu attends non ?
Moi j'ai bien un message:
"""
pushing to ..\repo1
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
"""
Sinon, quel est ton problème avec la création de branche ?
Quel message lors du push ?
Si tu crées une branche, il faut la créer une fois et la pusher.
Il faut pas la recréer sur le clone distant.
[^] # Re: hg
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 2.
Lorsque tu dis que tu as laissé tombé le plugin poussif tu parles de celui de Hg "achement mieux gaulé" que celui de git.
Tu peux préciser (on envisage un passage sous Hg au taf).
[^] # Re: hg
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 2.
Tu confirmes ?
[^] # Re: On sera au mois un!
Posté par El Titi . En réponse au journal Framasoft cherche volontaires pour traduire un livre d'initiation au JavaScript. Évalué à 5.
[^] # Re: Pauvre torchon
Posté par El Titi . En réponse à la dépêche ChiliProject: Redmine forké. Évalué à 4.
...
ChiliProject
...
Qui devinera le nom des 2 prochain forks (référence au rock californien needed) ?
[^] # Re: oui mais le logiciel privateur, c'est pareil
Posté par El Titi . En réponse au journal It's a Long Way to the Top (If You Wanna Rock 'n' Roll). Évalué à 2.
En revanche, le profiler de C++ était une rolls, il m'a sauvé la mise plus d'une fois.
[^] # Re: oui mais le logiciel privateur, c'est pareil
Posté par El Titi . En réponse au journal It's a Long Way to the Top (If You Wanna Rock 'n' Roll). Évalué à 2.
Au départ on avait Netbeans, l'ide de Borland et IntelliJ.
IBM a compris qu'il étaient à la ramasse, ont libéré le core et ca a tué la concurrence.
Sun a libéré Netbeans après coup et la sauce n'a jamais pris.
IntelliJ a libéré aussi son core depuis et la division IDE de Borland est morte.
[^] # Re: c'est pas franchement grave
Posté par El Titi . En réponse à la dépêche Rififi autour de Subversion. Évalué à 3.
i.e que tu définis des articles de configuration qui ne sont pas de simples fichiers et qui obéissent à leur propre cycle de vie.
C'est le pendant coté GCL de l'architecture à base de composants
http://en.wikipedia.org/wiki/Component-based_software_engine(...)
Ton application est un simple assemblage de plusieurs versions de composants.
Un composant peut être réutilisable dans plusieurs projets différents, modifiable ou non dans le projet.
On est soit fournisseur, soit consommateur du composant.
Si c'est un composant binaire et que tu es consumer et que tu n'a pas besoin de faire évoluer les sources tu t'en sors avec des outils comme Maven et un VCS est superflu sinon c'est utile.
UCM et Clearcase gère ça pas trop mal.
SVN le fait grâce au svn copy ("cheap copies") et aux svn:externals
Avec mercurial il faut utiliser le submodules et il doit y avoir un équivalent sous Git.
http://stackoverflow.com/questions/2479274/using-mercurial-i(...)