flyer a écrit 73 commentaires

Lien qui explique tout ça
http://svnbook.red-bean.com/html-chunk/ch04s03.html(...)

en résumé:
- je corrige un bug dans la branche nommée "superdev". Je commit la branche et le repository incrémente le numéro de révision. Disons que le nouveau numéro de révision est 123.
- maintenant je veux appliquer cette correction de bug dans la branche principale (nommée trunk) je n'ai qu'à faire :
svn mergre -r 122:123 http://svn.example.com/repos/branches/superdev(...)

Même si la correction de bug intervient sur plusieurs fichiers, toutes les modifications seront appliquées à la branche principale.

Plus dans le détail:

positionnement sur la branche superdev:
# svn switch http://svn.example.com/repos/branches/superdev(...)

modifications des fichiers de la branche, commit:
# svn commit
(nouveau numéro de révision 123)

repositionnement sur la branche trunk:
# svn switch http://svn.example.com/repos/trunk(...)

application de ces modifications sur cette branche:
# svn mergre -r 122:123 http://svn.example.com/repos/branches/superdev(...)

commit:
#svn commit

On peut aussi répliquer plusieurs ensembles de modifications (c'est à dire plusieurs commits ou plusieurs corrections de bug) d'un seul coup, d'une branche à l'autre de la même manière. Il suffit pour ça de jouer avec les -r 999:999. Je crois que tant que l'on a pas lu le SVN Book on ne sait pas vraiment ce qu'est subversion:
http://svnbook.red-bean.com/html-chunk/index.html(...)

Pour la comsmétique :
svn log -xml > log.xml
Ensuite il ne reste qu'à écrire un fichier XSL (ou en reprendre un d'internet il en existe déjà) et à le passer dans un processeur XSLT (sablotron par exemple) et voilà un changelog tout beau tout bien présenté.

Utilises toirtoiseSVN ou rapidSVN.

Subversion apporte aussi:
- commit atomique (LA fonctionnalité qui manque dans CVS)
- gestion des branches et des tags extrêmement simple
- réplication des corrections de bugs entre les branches extrêment simple.
- renommage/déplacement des fichiers et répertoires avec conservation de l'historique

Je suis plutôt contre le reserved checkout mais helas il y a des cas où il est indispensable. Par exemple prenons un fichiers binaire (genre une analyse, un schema ou un document OpenOffice, bref une documentation dans un format binaire) et bien si 2 personnes travailles séparément sur la même version fichiers imaginez le boulot que ça va induire lorsque la 2ieme personne voudra commiter. Elle sera obligé de faire un merge à la mano et donc se rappeler de tout ce qu'elle a changé car le logiciel de version ne pourra pas lui indiquer les différences.
Dans ce cas la seul solution c'est le dialogue. Les personnes succeptibles de travailler sur ces fichiers doivent communiquer pour indiquer lorsqu'elles travaillent dessus.

Et aussi le renommage et le déplacement des fichiers. On peu renommer un fichier et/ou le déplacer et son historique est conservé. Il y a aussi la gestion des branches et des tags qui est beaucoup plus simple car KISS powered.
Mais la grande nouveauté par rapport à CVS est bien le commit atomique.
Ce commit atomique permet, entre autre, de répliquer rapidement des correction de bugs d'une branche à l'autre.

"- penetration tools "
C'est du double emploi. Tout bon homme qui se respecte a déjà en sa possetion un tel outil.
Vous donnez pas cette peine, je ---->[].

C'est déjà la cas sur plusieurs sites web, et certainement chez certains assembleurs.

Il manque le choix: en HTML bourré de tableaux moyen-âgeux (et je ne compte rien faire)

grsec? Kesako ?

Plus fiable ne veut pas dire infaillible.

Ca ne change rien. Comment accorder une confiance à quelque'un? Et rien n'empêche quelqu'un de briser ta confiance... La confiance ne veut pas dire risque 0. Il y aura bien toujours des risques. Il est impossible d'être sûr à 100%.

Il n'y a aucune solution fiable à 100%. Un mainteneur peu tout à fait passer du coté obscur et fournir une version contenant un trojan. Cette nouvelle version aura son MD5 et tout sera considéré comme "de confiance". Un autre cas serait que le mainteneur inclu des patchs provenant de quelqu'un qu'il considère lui-même de confiance sans trop y regarder de pres et on retombe dans le même cas si ces patchs contiennent un trojan. Un dernier cas serait l'usurpation d'identité du mainteneur. Dans ce cas une tierce personne fournirait une version en se faisant passer pour le mainteneur (en lui volant sa clé privé ou ses mots de passes...)

Bref vous l'aurez comprid il est impossible d'être sûr à 100%. Tout ce qu'on peu faire pour que tout se passe au mieux est de toujours avoir accès au code source et de rester vigilant afin de minimiser les pertes et vols de données. On ne pourra jamais les empêcher.

Bien au contraire je trouve ça bien. Je suis un fervant défenseur des logiciels libres et je ne vois pas pourquoi ils devraient avoir un traitement de faveur. Ils doivent justement etre exposé à la même agressivité des pirates pour prouver qu'il sont plus fiable.

La machine était à jour. Elle a été piraté avant la diffusion du correctif.

Est-ce qu'on ne perd pas quelques avantages de IPV6 en l'encapsulant dans du IPV4?

s/librarie/bibliothèque/g

Très simple tu mets une section critique tout autours des accès à la base et tu obtient un serveur itératif plutot qu'un serveur concurenciel. C'est une solution qui peu etre tout à fait viable pour des serveurs supportant peu de requetes. (moins de 10 par secondes).

Savoir ce qu'est un firewall et le configurer de quelconque manière que ce soit, pour un débutant ça ne sera jamais simple.

N'y aurait-il pas un jeu de mot que tu n'aurais pas comprid?

Ca parait évident, pourquoi n'y ait-je pas pensé avant. Merci cafard.

Je suis dans une société qui fait du NAT pour donner l'accès internet à ses employers. 2 personnes de cette même société avec un comptes DLFP différent ne peuvent donc pas voter au même sondage. Inversement une même personne disposant de plusieurs accès internet pourras voter plusieurs fois avec le même compte DLFP. Helas je ne vois pas de solution technique à cela...

bibliothèque, c'est trop difficile à assimiler?