http://trac.rezo.net/trac/spip/changeset/13904 ayant introduit une
modif des bases gerees par la branche dev, et
http://trac.rezo.net/trac/spip/changeset/13929 opérant un nouveau
changement dans la base, un site qui aura suivi le chemin "dev" aura
la modif 13904, tandis qu'un site sur le chemin "stable" ne l'aura
pas. D'où potentiellement un problème lorsqu'on fera un svn switch.
Comment gérer ce cas de figure ?
C'est peut-être dû à mon inactivité spipienne ces derniers temps,
mais je ne comprends pas où est la nouveauté.
Si on bascule de la stable vers la dev, on aura les MAJ 904 et 929
car le numéro de version de la base en 2.0 est largement inférieur, c'est ok.
Basculer de la dev vers la stable, ça veut dire qu'on installe une version antérieure
de SPIP sur une base postérieure, et ça on a toujours dit qu'il ne fallait pas le faire,
le fait que ce soit avec "svn switch" ne change rien à l'affaire.
Mais je n'ai peut-être pas compris.
Committo,Ergo:Sum
Si on bascule de la stable vers la dev, on aura les MAJ 904 et 929
car le numéro de version de la base en 2.0 est largement inférieur, c'est
ok.
Non, justement c'est là qu'on coince : le numéro de version est le
même des deux côtés.
-- Fil
Non, justement, il a fallu faire un upgrade de base sur la stable qui a maintenant le numéro 929
Donc si un bascule une stable en svn, on saute la maj 904 qui n'existe pas en stable
On avait évoqué ce problème au moment de la suppression des infos de branche dans les versions de base.
Cédric
Je ne comprend pas. Dans /branches/spip-2.0/ecrire/inc_version.php je lis:
// version de la base SQL (= numero SVN de sa derniere modif)
$spip_version_base = 13833;
comment a pu être fait un upgrade 13929 dans ces conditions ?
Committo,Ergo:Sum
Ah exact il n'a pas encore été fait, fil n'ayant commit que sur le tronc en attendant de savoir quoi faire sur la branche stable
http://trac.rezo.net/trac/spip/changeset/13929
Le problème reste entier : il s'agit d'un upgrade qu'il faut faire sur la stable pour réparer la base cassée.
Cédric
Bon, je commençais à me demander si je n'étais pas devenu complètement incompétent.
En l'espèce, la modif 13904 consiste seulement à rajouter un champ dans une table,
la stable peut donc recevoir cette modif sans perturber son fonctionnement.
C'est évidemment tricher face au problème, mais un fork sur les bases
(et donc les sauvegardes) me semble devoir être évité autant que possible.
Committo,Ergo:Sum
En l'espèce, la modif 13904 consiste seulement à rajouter un champ dans une
table, la stable peut donc recevoir cette modif sans perturber son fonctionnement.
Bien sûr on peut baser nos mises à jour sur une analyse de la base
plutôt que sur un numéro de version. Ca permettrait de forker/déforker
plus librement.
C'est évidemment tricher face au problème, mais un fork sur les bases
(et donc les sauvegardes) me semble devoir être évité autant que possible.
C'est ce que je voulais dire en fait 
-- Fil