Reprise du message précédent :

 
 
Faut reussir à le placer dans 15 topics en moins d'une heure ?

Pas d'accord, ça peut être intéressant pour remonter à la source de pourquoi un truc a été fait comme ça, ou pour explorer les sources d'un bug (genre si on sait que perdu dans le tas il y a une version qui a pas le bug on peut faire une recherche par dicho toussa)

totozifiant

 
Oui, bien sûr, mais bon, dans notre cas, c'est vraiment se faire chier pour rien : le repository svn est géré comme une merde, y'a pas de tags....enfin, c'est la fête, quoi.
 
 

y'a pas de tags, bein voyons

 
Avant que j'arrive, ils n'utilisaient pas de tags.
Et on en utilisera que quand on aura réorganisé tout le repository : actuellement, chaque projet client est un repository SVN, avec des liens entre eux...C'est pas mal, sauf que les couches basses, les API communes, etc...au lieu d'être un projet à part, versionné, taggé, et tout, ben chaque dev en récupère les source (parfoiqs en read-only), et les recompile pour builder son projet..
Non, mais bon, c'est une utilisation totalement tordue du truc, mais pour le moment, je dois faire avec.

http://downhereintexas.com/text/AdviceTX.txt

* ça fait 5 ans aujourd'hui que taiche pourrit hfr *

noob.

plus de 7 ans pour moi

vos gueules, et répondez à la question

 
merde >.< moi aussi :x enfin j'ai pas trop pourri

Pareil    
 
Question SVN (c'est de circonstance ce matin alors j'en profite, Masklinn est chaud du coup ) :
Je veux connaitre les fichiers modifiés/supprimés entre 2 révisions (dans le but ensuite de me faire un système de mise à jour de mon appli).
Pour l'instant pour récupérer cette liste je me base sur ça (appelé dans un script en bash) :

 
Y a mieux et + fiable ?
 
Car je viens de constater un souci sur le svn diff (ptet un bug) : j'ai une ligne qui ressemble à ça

J'ai un caractère ^M qui vient foutre la merde.
Alors je peux toujours m'arranger pour faire un sed pour nettoyer mais c'est crade je trouve.

c'est totozifiant

Les tags, c'est utile pour savoir qu'une révision a un nom (ou pour binder une release à une révision), c'est grave nive, mais avoir tout l'historique sans les tags c'est quand même plus intéressant qu'avoir les tarball des releases sans le reste de l'historique imho

svn log -v -r ${SOURCE_REVISION}:${TARGET_REVISION} ${SVN_REPOSITORY} et quelques traitements autour, ça me semble pas mal
 
no?
 
edit: et si tu veux faire un truc un peu plus classieux qu'un script bash, tu ajoutes --xml pour sortir du XML et tu files ça à e.g. un script Python ou Ruby, t'auras pas à parser du freeform.

 
Les tags, ça serait surtout utile pour savoir ce qu'ils ont livré chez les clients   Pasque là, à part décompiler les jars de l'appli, on peut pas récupérer les sources d'une version installée.
 
Quand j'ai fait remarquer ça, on m'a répondu "ouais, mais en fait, on s'en fout : si un client a un problème, on le corrige dans la head revision   "
Et si on arrive pas à reproduie? Ben on s'en fout, c'est que le bug est parti
 

HI FAGGOTS

 
Dans l'absolu, je ne vois pas de probleme majeur avec ce comportement. Bon, evidemment, c'est mieux avec un bug tracking qui liste les corrections qui sont faites dans le HEAD, mais sinon, tant que le client recoit des revisions regulierement...

en général les clients préfèrent avoir les corrections de bugs et les régressions séparément.

 
Bah...Je trouve ça moyen. En plus, je suis sûr que ça peut être automatisé par le machin qui fait les builds pour livraison ; il enlèverai le tag "livraison", et le recollerai sur la head revision après avoir buildé, on y verrait que du feu.
Parce que là, vu que nos repository sont liés entre eux, si il y a un bug sur le projet truc, dans une partie partagée avec le projet machin, les corrections vont impacter les 2 projets....Bonjour les effets de bords potentiels.

BT §§§§§§§§§

Un avis sur le suivi de version pour la improver la qualité du back tracking, Expert Stiffler?

C'est parti pour le svn log --xml -v
 
Par contre ce sera en PHP le script, avec simplexml ça va aller vite en +

 
Ca depend vraiment des milieux. J'ai eu a faire avec les deux types de clients (ultra-frileux et early-adopter), et y a pas moins de soucis avec l'un que l'autre. La difference, c'est surtout dans la rapidite de correction des bugs.
 

 
Euh... ouais, ca veut dire que dans aucun des projets qui utilise le bordel commun, il n'y a de test qui a decouvert la faille avant le projet. A ce niveau, c'est plus l'ensemble du processus de developpement qu'il faut remettre en cause...

skeye ...

 
 
je cherche une sorte de CMS de base de de connaissance du style :
http://www.knowledgebase-script.co [...] le-19.html
 
en existe il des gratuits dans ce genre la?
 
merci

 
Ca dépend, si la faille dans le projet vient d'une spécificité du jeu de données chez le client, bon.
Mais sinon, oui, il faut mettre l'ensemble du process de développement à plat. C'est pour ça que je suis là! Mais pour le moment, il a fallu gérer l'urgence. Normalement, on va tout péter très vite.

j'peux venir ? tu as quelle latitude dans la remise à plat ?

j'achete un i et un e

LOL, CHSNAPNAMM

si tu ressembles à ton avatar il faut t'acheter un regime

Hahaha... Wait, no...

personne pour me renseigner sur ma recherche?

 
Je sais pas! Si un poste est ouvert, je t'en parlerai.
Sinon, j'ai une lattitude...disons assez large, sachant qu'on part de très loin.  
Première étape : mise en place de trucs genre log4j, création de projets EJB sous Eclipse pour les EJB (là, ils font le déploiement pour test à la main, avec un build ant pour chaque EJB ), exposition aux collègues incrédules de la perspective "debug" d'Eclipse, avec les breakpoints et tout.....
 
 
 
voilà!! Le but, dans un premier temps :  

• inculquer qques bonnes pratiques en Java (comme utiliser Map au lieu de Hashtable, par exemple)
• découper le projets en bouts cohérents,
• introduire des tas de librairies bien pratiques, comme log4j, par exemple, et refactorer le code pour s'en servir,
• refaire la gestion d'erreurs,
• introdure une nouvelle méthode pour le rendering (pour le moment, c'est une api faite par MCK Hollande, qui fait des out.println dans la méthode doView des portlets)
• factoriser du code, y'en a plein en trop
• faire du monitoring, je suis sûr qu'on est catastrophique en perf,
• .............

 
kitétoua ?

noobot

putain je HAIS les boites vocales qui t'empêchent de patienter 30 secondes, "toutes nos lignes sont occupées, réessayez plus tard, et avec un peu de bol, vous tomberez sur la demi-secondes où quelqu'un est libre ! "

 
C'était pas un post de bot
Et sa blague était pourrie