Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

rub
2009-12-10 14:01:25

Eric a écrit:

plg a écrit:

Ensuite, si eric fait ses modifs sur une vieille revision du fichier (qui ne prend pas en compte la suppression du $Id par exemple), quand il va vouloir commiter, SVN va l'envoyer sur les roses : une nouvelle revision impacte ce fichier, merci de faire un update d'abord. En faisant l'update, il va fusionner les changements avec sa version locallement modifiée. Après libre à Eric de faire une copie par dessus de son fichier qu'il avait mis de côté et qui n'a pas subi la fusion. Il faut vraiment savoir ce qu'on fait par contre dans ce genre de cas.

Euh... Là, çà n'a pas du tout fonctionné comme cela chez moi. Si je n'ai pas travaillé sur un copie à jour, SVN ne m'a jamais dit qu'il y avait un pb avec mon commit. J'ai livré et c'est passé. Sans autre forme de procès... :-/

Il suffit d'avoir le fichier ouvert en cours de modif, de remettre une copie de sauvegarde, de travailler en dehors de ton espace de travail et le tour est joué..

rub
2009-12-10 14:00:05

Eric a écrit:

plg a écrit:

On parle de faire un "checkout" avant chaque commit. N'est-ce pas plutôt un "update" ? Je n'utilise pas TortoiseSVN mais s'ils appellent ça "checkout", c'est sacrément déroutant pour ceux qui connaissent le vocabulaire Subversion.

Je confirme avec Tortoise SVN, c'est bien SVN mettre à jour (mauvaise reprise sans réfléchir des mots de Rub dans son topic initial) et c'est ce que je fais avant toute modification de code.

J'ai utilisé check out car moi, je fais des check out... (en gros, j'ai un script que j'appelle "sync" pour synchroniser mes aires de travail et dans ce script, je fais des "svn co" et ne voulant parle de synchro, je me suis fourvoyé en parlant de checkou)...
Je fais des updates que pour avoir une révision particulière...

En pratique, faire un update ou check out sur ton espace de travail ca revient au même (ou presque)... en tout cas, il indique s'il y a des merges manuels à faire et ca fait les merges automatiques...
Je sens que les foudres qui vont s'abattre sur moi... ;)

Eric
2009-12-10 13:00:25

plg a écrit:

Bonjour à vous développeurs francophones qui discutent de dev en français (il y a un message subliminal dans cette introduction, saurez vous le déceler ?)

Message subliminal reçu. [mode Calimero = ON]Mais... Euh... C'est pas moi qui ait commencé ! ;-) [/mode Calimero = OFF]

plg a écrit:

On parle de faire un "checkout" avant chaque commit. N'est-ce pas plutôt un "update" ? Je n'utilise pas TortoiseSVN mais s'ils appellent ça "checkout", c'est sacrément déroutant pour ceux qui connaissent le vocabulaire Subversion.

Je confirme avec Tortoise SVN, c'est bien SVN mettre à jour (mauvaise reprise sans réfléchir des mots de Rub dans son topic initial) et c'est ce que je fais avant toute modification de code.

plg a écrit:

Ensuite, si eric fait ses modifs sur une vieille revision du fichier (qui ne prend pas en compte la suppression du $Id par exemple), quand il va vouloir commiter, SVN va l'envoyer sur les roses : une nouvelle revision impacte ce fichier, merci de faire un update d'abord. En faisant l'update, il va fusionner les changements avec sa version locallement modifiée. Après libre à Eric de faire une copie par dessus de son fichier qu'il avait mis de côté et qui n'a pas subi la fusion. Il faut vraiment savoir ce qu'on fait par contre dans ce genre de cas.

Euh... Là, çà n'a pas du tout fonctionné comme cela chez moi. Si je n'ai pas travaillé sur un copie à jour, SVN ne m'a jamais dit qu'il y avait un pb avec mon commit. J'ai livré et c'est passé. Sans autre forme de procès... :-/

plg a écrit:

Eric, saches que sur le forum, il y a de la syntaxe magique, tu peux mettre "svn : 1234" (sans les espaces) et ça va se transformer en un superbe lien vers code.piwigo.org (et peut-être autre chose demain, en tout cas c'est pérenne).

Oui, je sais. J'étais à la bourre hier lorsque j'ai posté et je n'ai pas réfléchi plus que çà... Mea culpa.

ddtddt
2009-12-10 09:03:19

avec le fichier FR sur tortoise c'est

SVN Mettre à jour
SVN Livrer
TortoiseSVN >

;-)

VDigital
2009-12-10 07:35:32

"TortoiseSVN s'ils appellent ça "checkout"" : Je te rassure le clic droit indique dans l'ordre:

SVN Update
SVN Commit...
TortoiseSVN >


ou
SVN Checkout...
TortoiseSVN >

plg
2009-12-10 01:24:30

Bonjour à vous développeurs francophones qui discutent de dev en français (il y a un message subliminal dans cette introduction, saurez vous le déceler ?)

On parle de faire un "checkout" avant chaque commit. N'est-ce pas plutôt un "update" ? Je n'utilise pas TortoiseSVN mais s'ils appellent ça "checkout", c'est sacrément déroutant pour ceux qui connaissent le vocabulaire Subversion.

Ensuite, si eric fait ses modifs sur une vieille revision du fichier (qui ne prend pas en compte la suppression du $Id par exemple), quand il va vouloir commiter, SVN va l'envoyer sur les roses : une nouvelle revision impacte ce fichier, merci de faire un update d'abord. En faisant l'update, il va fusionner les changements avec sa version locallement modifiée. Après libre à Eric de faire une copie par dessus de son fichier qu'il avait mis de côté et qui n'a pas subi la fusion. Il faut vraiment savoir ce qu'on fait par contre dans ce genre de cas.

Eric, saches que sur le forum, il y a de la syntaxe magique, tu peux mettre "svn : 1234" (sans les espaces) et ça va se transformer en un superbe lien vers code.piwigo.org (et peut-être autre chose demain, en tout cas c'est pérenne).

Eric
2009-12-09 21:18:26

J'ai commité [Subversion] r4455 après test en local et checkout préalable. Cà devrait le faire maintenant...

Eric
2009-12-09 18:06:40

Je fais pourtant un checkout avant de d'appliquer mon code dans les fichiers puis je commit.

Mon trunk est actuellement à la dernière révision r4445 et user_list.tpl n'a que le {id} "en trop". Je pense que je peux appliquer la correction et virer ce {id} par la même occasion, non ?

rub
2009-12-09 17:44:32

Eric a écrit:

Mais je ne comprends pas comment cela a pu arriver. Je ne me rappelle absolument pas avoir touché à la partie NAVBAR pour cette révision. Je commit la correction...

Tu n'as touché à rien, tu es juste parti d'une mauvaise version.

Par exemple, tu fais tes modifs, tu commites et tu fais un checkout...
Avant de commiter, je fais toujours un checkout et je vois s'il n'y pas de conflit.

Je penses que le plus simple pour corriger, c'est de faire des merges des révisions.
plg un petit coup de main?

Eric
2009-12-09 17:38:34

Ok, j'ai pigé...

Mais je ne comprends pas comment cela a pu arriver. Je ne me rappelle absolument pas avoir touché à la partie NAVBAR pour cette révision. Je commit la correction...

rub
2009-12-09 17:34:44

Eric a écrit:

Je ne vois pas comment [Subversion] r3751 aurait pu annuler annuler les révision précédentes qui n'ont aucun lien avec r3751.

Une synchro sur ton poste et tu es parti de la mauvaise version.
Le diff est pourtant clair. Ligne 93/95.

Eric a écrit:

D'ailleurs, il y a un autre problème : Le diff de [Subversion] r3751 ne colle pas avec ce que j'ai commité. A l'époque, je me suis fait "gronder" par Nicolas par ce que j'avais re-commité les fermetures de balises uniques dans les tpl. Cela a été corrigé dans la foulée si je me souviens bien.

Oui dans [Subversion] r3752 mais en partant de ce que tu avais fait.


Eric a écrit:

Pour le problème de NAVBAR, d'après le journal des révisions de mon Tortoise SVN, c'est suite au déplacement et recodage de la fonction create_navigation_bar() de ../incude/functions_html.inc.php vers ../include/functions.inc.php que le problème apparait.

Justement, P@t avait fait le nécessaire mais ca été écrasé... Comme la suppression des {id} par plg.

Eric
2009-12-09 17:25:53

Je ne vois pas comment [Subversion] r3751 aurait pu annuler annuler les révision précédentes qui n'ont aucun lien avec r3751.

D'ailleurs, il y a un autre problème : Le diff de [Subversion] r3751 ne colle pas avec ce que j'ai commité. A l'époque, je me suis fait "gronder" par Nicolas par ce que j'avais re-commité les fermetures de balises uniques dans les tpl. Cela a été corrigé dans la foulée si je me souviens bien.

Pour le problème de NAVBAR, d'après le journal des révisions de mon Tortoise SVN, c'est suite au déplacement et recodage de la fonction create_navigation_bar() de ../incude/functions_html.inc.php vers ../include/functions.inc.php que le problème apparait.

rub
2009-12-09 15:32:12

http://code.piwigo.org est revenu.

Il y a regression à partir du [Subversion] r3751 qui annule ce qui a été fait dans [Subversion] r3172 , [Subversion] r3282 et [Subversion] r3283 .
Cf [Bugtracker] ticket 1041

rub
2009-12-09 14:13:42

Uniquement dans la version trunk, la barre de navigation dans la liste des utilisateurs en admin affiche "Array" au lieu des liens.

En mettant

Code:

{if !empty($navbar) }{include file='navigation_bar.tpl'|@get_extent:'navbar'}{/if}

au lieu de

Code:

<div class="navigationBar">{$NAVBAR}</div>

et

Code:

$template->assign('navbar', $navbar);

en miniscules ca va mieux.

Par contre, http://code.piwigo.org/ étant cassé pour le moment, je n'ai pas pu trouver le commit qui a entrainé ce dysfonctionnement.
En fait, je voudrais connaitre la nouvelle méthode à utiliser pour les navbars! Et indiquer au développeur le bug engendré.

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact