si les branches ne sont pas des vraies branches dans le sens qu'elles
ne vont pas évoluer indépendamment dans le future:
e.g. tu as une version 1.9.2 stable et fonctionnelle et tu fais juste
de la maintenance pour que ce soit compatible 1.9.3,
alors il n'y a pas besoin de brancher en répertoires, juste de dire à
archivelist.txt de generer deux archives différentes en spécifiant le
numeros du commit à partir duquel il y a différence...
Par exemple:
_plugins_/_stable_/agenda/1_9_1:8642;agenda_1_9_1
_plugins_/_stable_/agenda/1_9_2:13400;agenda_1_9_2
_plugins_/_stable_/agenda/1_9_2;agenda_1_9_3
Ce n'est pas ce qui se faisait avant, mais depuis que Toggg a ajouté
cette option dans archivelist, c'est à l'usage le plus simple et ça
évite de se planter avec les svn copy et move.
Pierre
On 10/3/07, Nicolas Hoizey <nicolas@hoizey.com> wrote:
> Et hop, un SVN move de raté, un historique de perdu
Bin oui, je m'en suis excusé, je suis dégoûté !
C'est quoi qu'il faut faire exactement, pour gérer proprement un
trunk et des branches, dans la zone ?
si les branches ne sont pas des vraies branches dans le sens qu'elles
ne vont pas évoluer indépendamment dans le future:
e.g. tu as une version 1.9.2 stable et fonctionnelle et tu fais juste
de la maintenance pour que ce soit compatible 1.9.3,
alors il n'y a pas besoin de brancher en répertoires, juste de dire à
archivelist.txt de generer deux archives différentes en spécifiant le
numeros du commit à partir duquel il y a différence...
Sauf que là, ceux qui n'utilisent les plugins qu'avec un checkout de la zone -- comme moi -- n'auront que la dernière version, même s'ils sont toujours sur une « ancienne » version de SPIP...
J'ai regardé notamment les arbo des plugins acces_groupes, agenda, forms, FpipR, etc. avant de partir comme je l'ai fait.
Il me semble qu'il pourrait être intéressant de convenir tous ensemble d'un mode de fonctionnement homogène pour cette gestion des branches de maintenante des plugins.
Sauf que là, ceux qui n'utilisent les plugins qu'avec un checkout de
la zone -- comme moi -- n'auront que la dernière version, même s'ils
sont toujours sur une « ancienne » version de SPIP...
Bon, finalement j'ai fait un sabot pour l'instant, on verra plus tard si une branche se justifie.
si les branches ne sont pas des vraies branches dans le sens qu’elles
ne vont pas évoluer indépendamment dans le future:
e.g. tu as une version 1.9.2 stable et fonctionnelle et tu fais juste
de la maintenance pour que ce soit compatible 1.9.3,
alors il n’y a pas besoin de brancher en répertoires, juste de dire à
archivelist.txt de generer deux archives différentes en spécifiant le
numeros du commit à partir duquel il y a différence…
Sauf que là, ceux qui n’utilisent les plugins qu’avec un checkout de
la zone – comme moi – n’auront que la dernière version, même s’ils
sont toujours sur une « ancienne » version de SPIP…
+1
Pour la branche habituellement je passe par un client svn et je fais un svn copy avec mode recursif du repertoire du plugin.
Dans tortoise je le fais directement dans l’explorateur de repository avec l’option copy to
