[SPIP Zone] nouveau dépôt sur la zone

Oops, je renvoie à partir de la bonne adresse …

Hello la zone

Je voudrais créer une nouvelle branche pour Escal

Pour l’instant en local, la version 4 est branchée sur la /branche_V3 et je voudrais la déposer dans un nouveau dossier /branche_V4

J’utilise RabbitVCS sous linux car pas à l’aise avec les lignes de commande mais je n’ai pas envie de faire une mauvaise manip.

Donc si je fais ce qui est sur cette image, est-ce que je vais bien

  • ne rien enlever de /branche_V3 ?

  • créer le dossier /branche_V4 ?

  • déposer les fichiers de la V4 dans /branche_V4 ?

adeobbciegdmappg.png

Merci pour vos réponses

Le 16/12/2017 à 22:21, Jean-Christophe Villeneuve a écrit :

Oops, je renvoie à partir de la bonne adresse ...

Hello la zone

Je voudrais créer une nouvelle branche pour Escal

Pour l'instant en local, la version 4 est branchée sur la /branche_V3 et je voudrais la déposer dans un nouveau dossier /branche_V4

Non ce n’est pas du tout un svn relocate à faire !

Le plus simple à mon sens est que tu parte du dépot racine.

Imaginons que tu gardes tes modifs sous le coude quelques temps au chaud ("Pour l'instant en local, la version 4..." tu la gardes dans un répertoire, disons nommé "futur_escal")

Tu télécharges ailleurs (dans un autre répertoire) le dépot racine d’escal (_squelettes_/escal/ sur la zone), ce qui te donnera un répertoire avec les 3 répertoires actuels dedans (branche_v2, branche_v3 et branche_v3b). Tu ne touches pas à leurs fichiers.
En svn ce serait ceci (créerait un répertoire mon_escal) :
svn checkout svn://zone.spip.org/spip-zone/_squelettes_/escal mon_escal

Tu copies (en SVN) ensuite la branche qui t’a servie de base pour ta v4 à toi dans le répertoire branche_v4. En ligne de commande ça serait (si tu es partie de la v3) :

cd mon_escal
svn cp branche_v3 branche_v4

À partir de ce moment là tu as donc un nouveau répertoire local branche_v4 identique à branche_v3 et SVN sait que sa maman, c’est la branche v3 (c’est bien pour l’historique).

Ensuite, brutalement tu supprimes ce répertoire branche_v4 à la main, et tu le remplaces par celui de ton futur contenu (sans le .svn éventuel).

rm -rf branche_v4
cp -r ../futur_escal branche_v4
rm -rf branche_v4/.svn

À partir de là, tu as presque tout… sauf que des fichiers sont peut être différents (ajoutés / supprimés) entre les 2 branches.
Un statut doit te l’indiquer

svn status

Pour tous les fichiers "!" (manquent en local), faire un svn delete fichier.ext (un svn status ensuite le montre "D" : deleted)
Pour tous les fichiers "?" (inconnus sur le dépot, et que tu veux envoyer), faire un svn add reportoire ou svn add fichier.ext (un svn status ensuite le montre "A" (added)

Une fois ceci fait, commiter.
svn commit branche_v4 -m "Ma nouvelle branche de folie"

Voilà pour le principe.
Maintenant là c’est en ligne de commande. Avec ton explorateur de fichier et l’outil Tortoise ou autre, tu dois pouvoir faire les mêmes commandes. Mais je connais pas.

MM.

J'utilise RabbitVCS sous linux car pas à l'aise avec les lignes de commande mais je n'ai pas envie de faire une mauvaise manip.

Donc si je fais ce qui est sur cette image, est-ce que je vais bien

  * ne rien enlever de /branche_V3 ?
  * créer le dossier /branche_V4 ?
  * déposer les fichiers de la V4 dans /branche_V4 ?

Merci pour vos réponses

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Le 16/12/2017 à 22:21, Jean-Christophe Villeneuve a écrit :

Oops, je renvoie à partir de la bonne adresse ...

Hello la zone

Je voudrais créer une nouvelle branche pour Escal

Pour l'instant en local, la version 4 est branchée sur la /branche_V3 et je voudrais la déposer dans un nouveau dossier /branche_V4

J'utilise RabbitVCS sous linux car pas à l'aise avec les lignes de commande mais je n'ai pas envie de faire une mauvaise manip.

Donc si je fais ce qui est sur cette image, est-ce que je vais bien

  * ne rien enlever de /branche_V3 ?
  * créer le dossier /branche_V4 ?
  * déposer les fichiers de la V4 dans /branche_V4 ?

Merci pour vos réponses

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Hello JC

tu veux que je m'en occupe ?

si je comprends bien tu veux que ta nouvelle version 4 soit en trunk, que la version actuelle devienne la v3 en tag

c'est ça ?

--
Bonne journée
Arnaud B. (Mist. GraphX)

d'ailleurs au passage ça serais pas mal d'utiliser la structure de dossier normalisé : trunk, tags, branches

la version en cours (celle qui génére le paquet) étant dans trunk …

--
Bonne journée
Arnaud B. (Mist. GraphX)

Ah que oui, je veux bien que tu t’en occupes !

En fait pour l’instant, en local, j’ai 2 sites :

  • un en version spip 3.1.7 avec la version 3 d’escal
  • un en version spip 3.2 avec une future version 4 d’escal qui ne fonctionnera qu’à partir de la version spip 3.2 (pour l’affichage de l’agenda pleine page qui a changé) et comme c’est une copie modifiée de la version 3, rabbitVCS pointe encore vers /squelettes/escal/branche_v3

Je voudrais donc

  • garder la version 3 d’escal qui pourra encore évoluer (donc pas en tag si j’ai bien compris) dans son dossier /squelettes/escal/branche_v3
  • créer un dossier /squelettes/escal/branche_v4 où je pourrais déposer la version 4 d’escal

adeobbciegdmappg.png

ok donc si on suis la nomenclature, la version pour spip 3.2 serais le /escal/trunk la version en développement et emmenée a être
la version stable privilégiée

et la version pour < a spip 3.2 qui passerait en /escal/branche/3.1

ce qui donnerait

  • _squelettes
    • escal
      • branches
        - v3
      • tags
        - v2
      • trunk

reste a voir au niveau des paquets générés

_squelettes_/escal/branche_V2;escal_V2
_squelettes_/escal/branche_V3;escal_V3

qui deviendra

 _squelettes_/escal/tags/V2;escal_V2
 _squelettes_/escal/branches/V3;escal_V3
_squelettes_/escal/trunk/;escal_V4

Après pour ton soucis en local, normalement on commence par récupérer le nouveau trunk pour commencer la v4 dessus :
la tu te retrouve avec une copie local qui est mal branché et qui risque de te faire des conflits au premier commit.

généralement moi dans ce cas j’ai un script qui me supprime tout les fichiers .svn, ensuite je checkout mon nouveau trunk vide en local et ensuite je remet mes fichiers dedans pour faire mon premier commit…
je ne sais pas si c’est la meilleur méthode, …

ok ça me va comme ça pour l’arborescence de la zone

Mais pour mes sites en local, il ne suffit pas de relocaliser ou de changer l’url du dépôt ?

On verra ^^ tu me dira A mon avis non, ça marche quand on change d’url de base, pas de dossier/repo

Don j'ai fait les changements tu as donc un trunk tout vide pour acceuillir la v4, a priori tu as juste a faire un checkout du repertoire et a y glisser tes fichiers.

Pour les autres versions a ta place je ferais un checkout direct en local sans essayer de re localiser …

Le 17/12/2017 à 13:30, Jean-Christophe Villeneuve a écrit :

ok ça me va comme ça pour l'arborescence de la zone

Mais pour mes sites en local, il ne suffit pas de relocaliser ou de changer l'url du dépôt ?

Le 17/12/2017 à 12:42, Mist. GraphX a écrit :

ok donc si on suis la nomenclature, la version pour spip 3.2 serais le /escal/trunk la version en développement et emmenée a être
la version stable privilégiée

et la version pour < a spip 3.2 qui passerait en /escal/branche/3.1

ce qui donnerait

  * _squelettes
      o escal
          + branches
              # v3
          + tags
              # v2
          + trunk

reste a voir au niveau des paquets générés

|_squelettes_/escal/branche_V2;escal_V2 _squelettes_/escal/branche_V3;escal_V3 |

qui deviendra

|_squelettes_/escal/tags/V2;escal_V2 _squelettes_/escal/branches/V3;escal_V3 _squelettes_/escal/trunk/;escal_V4 |

Après pour ton soucis en local, normalement on commence par récupérer le nouveau trunk pour commencer la v4 dessus :
la tu te retrouve avec une copie local qui est mal branché et qui risque de te faire des conflits au premier commit.

généralement moi dans ce cas j’ai un script qui me supprime tout les fichiers .svn, ensuite je checkout mon nouveau trunk vide en local et ensuite je remet mes fichiers dedans pour faire mon premier commit…
je ne sais pas si c’est la meilleur méthode, …

Le 17/12/2017 à 11:50, Jean-Christophe Villeneuve a écrit :

Ah que oui, je veux bien que tu t'en occupes !

En fait pour l'instant, en local, j'ai 2 sites :

  * un en version spip 3.1.7 avec la version 3 d'escal
  * un en version spip 3.2 avec une future version 4 d'escal qui ne
    fonctionnera qu'à partir de la version spip 3.2 (pour
    l'affichage de l'agenda pleine page qui a changé) et comme c'est
    une copie modifiée de la version 3, rabbitVCS pointe encore vers
    /_squelettes_/escal/branche_v3

Je voudrais donc

  * garder la version 3 d'escal qui pourra encore évoluer (donc pas
    en tag si j'ai bien compris) dans son dossier
    /_squelettes_/escal/branche_v3
  * créer un dossier /_squelettes_/escal/branche_v4 où je pourrais
    déposer la version 4 d'escal

Le 17/12/2017 à 11:28, Mist. GraphX a écrit :

Le 16/12/2017 à 22:21, Jean-Christophe Villeneuve a écrit :

Oops, je renvoie à partir de la bonne adresse ...

Hello la zone

Je voudrais créer une nouvelle branche pour Escal

Pour l'instant en local, la version 4 est branchée sur la /branche_V3 et je voudrais la déposer dans un nouveau dossier /branche_V4

J'utilise RabbitVCS sous linux car pas à l'aise avec les lignes de commande mais je n'ai pas envie de faire une mauvaise manip.

Donc si je fais ce qui est sur cette image, est-ce que je vais bien

  * ne rien enlever de /branche_V3 ?
  * créer le dossier /branche_V4 ?
  * déposer les fichiers de la V4 dans /branche_V4 ?

Merci pour vos réponses

----
spip-zone@rezo.net -http://listes.rezo.net/mailman/listinfo/spip-zone

Hello JC

tu veux que je m'en occupe ?

si je comprends bien tu veux que ta nouvelle version 4 soit en trunk, que la version actuelle devienne la v3 en tag

c'est ça ?

--
Bonne journée
Arnaud B. (Mist. GraphX)

----
spip-zone@rezo.net -http://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net -http://listes.rezo.net/mailman/listinfo/spip-zone


--
Bonne journée
Arnaud B. (Mist. GraphX)

----
spip-zone@rezo.net -http://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

--
Bonne journée
Arnaud B. (Mist. GraphX)

Ok j’ai vu que tu avais créé les dossiers sur la zone

J’ai donc changer le chemin du navigateur de dépôt pour la branche escalV3

Je fais quoi maintenant pour la version 4 ?

Mist. GraphX a écrit le 17/12/2017 à 20:26 :

Don j'ai fait les changements tu as donc un trunk tout vide pour acceuillir la v4, a priori tu as juste a faire un checkout du repertoire et a y glisser tes fichiers.

Sauf qu'en faisant ça, ça va perdre tout l'historique du delta entre la V3 et la V4.

(oui, c'est compliqué de faire bien).

Et dans l'état actuel de ce qu'il y a sur la Zone, je ne vois pas bien comment faire.

Peut-être :
Dans Connexion · GitLab
Faire un svn cp de la branche v3
Ensuite, récupérer ce trunk en local.
Y mettre les nouveaux fichiers de la v4 (et enlever par les commandes SVN qui vont bien les fichiers et dossiers inutiles).
Et commiter avec un affreux log disant que c'est la v4, et qu'on ne voit que le différentiel entre la v3 et la V4, mais pas les étapes de ce différentiel.

PS : le but de cette manœuvre, c'est de conserver dans la V4 le fait qu'elle est la suite de la V3, avec tout l'historique de la V3 accessible.

--
RealET

As tu fais déjà beaucoup de modifs sur les fichiers ?

Le 17/12/2017 à 20:47, RealET a écrit :

Mist. GraphX a écrit le 17/12/2017 à 20:26 :

Don j'ai fait les changements tu as donc un trunk tout vide pour acceuillir la v4, a priori tu as juste a faire un checkout du repertoire et a y glisser tes fichiers.

Sauf qu'en faisant ça, ça va perdre tout l'historique du delta entre la V3 et la V4.

(oui, c'est compliqué de faire bien).

Et dans l'état actuel de ce qu'il y a sur la Zone, je ne vois pas bien comment faire.

Peut-être :
Dans Connexion · GitLab
Faire un svn cp de la branche v3
Ensuite, récupérer ce trunk en local.
Y mettre les nouveaux fichiers de la v4 (et enlever par les commandes SVN qui vont bien les fichiers et dossiers inutiles).
Et commiter avec un affreux log disant que c'est la v4, et qu'on ne voit que le différentiel entre la v3 et la V4, mais pas les étapes de ce différentiel.

PS : le but de cette manœuvre, c'est de conserver dans la V4 le fait qu'elle est la suite de la V3, avec tout l'historique de la V3 accessible.

Ce n'est pas optimal, effectivement

Le but c'était que jc se tape pas la diff de ses modifs, après je peut faire un copy du v3 actuelle dans le trunk

et il reporte ses modif pour avoir l'historique

--
Bonne journée
Arnaud B. (Mist. GraphX)

En fait, je n'ai pas vraiment besoin de l'historique de la V3 dans le V4

Le 17/12/2017 à 20:54, Mist. GraphX a écrit :

Le 17/12/2017 à 20:47, RealET a écrit :

Mist. GraphX a écrit le 17/12/2017 à 20:26 :

Don j'ai fait les changements tu as donc un trunk tout vide pour acceuillir la v4, a priori tu as juste a faire un checkout du repertoire et a y glisser tes fichiers.

Sauf qu'en faisant ça, ça va perdre tout l'historique du delta entre la V3 et la V4.

(oui, c'est compliqué de faire bien).

Et dans l'état actuel de ce qu'il y a sur la Zone, je ne vois pas bien comment faire.

Peut-être :
Dans Connexion · GitLab
Faire un svn cp de la branche v3
Ensuite, récupérer ce trunk en local.
Y mettre les nouveaux fichiers de la v4 (et enlever par les commandes SVN qui vont bien les fichiers et dossiers inutiles).
Et commiter avec un affreux log disant que c'est la v4, et qu'on ne voit que le différentiel entre la v3 et la V4, mais pas les étapes de ce différentiel.

PS : le but de cette manœuvre, c'est de conserver dans la V4 le fait qu'elle est la suite de la V3, avec tout l'historique de la V3 accessible.

Ce n'est pas optimal, effectivement

Le but c'était que jc se tape pas la diff de ses modifs, après je peut faire un copy du v3 actuelle dans le trunk

et il reporte ses modif pour avoir l'historique

Jean-Christophe Villeneuve a écrit le 17/12/2017 à 21:29 :

En fait, je n'ai pas vraiment besoin de l'historique de la V3 dans le V4

Toi ou nous ?
Tu es reparti de zéro ?
Si oui, pas besoin d'historique effectivement.
Si non, l'historique SVN fait partie de ce qu'il devrait conserver.

--
RealET

Le 17/12/2017 à 21:33, RealET a écrit :

Jean-Christophe Villeneuve a écrit le 17/12/2017 à 21:29 :

En fait, je n'ai pas vraiment besoin de l'historique de la V3 dans le V4

Toi ou nous ?
Tu es reparti de zéro ?
Si oui, pas besoin d'historique effectivement.
Si non, l'historique SVN fait partie de ce qu'il devrait conserver.

j'ai donc fait une copie dans /trunk

pour garder l'historique , tu peut donc récupérer ce dossier et reporter tes modification en passant le paquet a v4 pour commencer :wink:

--
Bonne journée
Arnaud B. (Mist. GraphX)

Ok un gran merci pour l'aide et pour la copie.

Pas tout compris cette histoire d'historique : puisqu'il existe dans la v3, pourquoi le garder dans la V4 ? Mais si vous dites que c'est mieux, je vous fais confiance.

Je verrai la suite demain à tête reposée mais si j'ai bien compris :

- je crée un dossier vide que je branche sur /trunk

- je mets à jour pour récupérer son contenu en local

- je fais mes modifs et je livre les modifs

Rien d'autre ?

Le 17/12/2017 à 21:39, Mist. GraphX a écrit :

Le 17/12/2017 à 21:33, RealET a écrit :

Jean-Christophe Villeneuve a écrit le 17/12/2017 à 21:29 :

En fait, je n'ai pas vraiment besoin de l'historique de la V3 dans le V4

Toi ou nous ?
Tu es reparti de zéro ?
Si oui, pas besoin d'historique effectivement.
Si non, l'historique SVN fait partie de ce qu'il devrait conserver.

j'ai donc fait une copie dans /trunk

pour garder l'historique , tu peut donc récupérer ce dossier et reporter tes modification en passant le paquet a v4 pour commencer :wink:

Le 17/12/2017 à 22:48, Jean-Christophe Villeneuve a écrit :

Pas tout compris cette histoire d'historique : puisqu'il existe dans la v3, pourquoi le garder dans la V4 ?

En cas de problème ou d'interrogation,
l'historique permet d'accéder aux diff de chaque commit qui permettent de comprendre,
avec en prime les explications données dans les logs de commits.

Que la branche s'appelle v4 ou v3 ou trunk ou dev ou wtf,
il faut donc pouvoir accéder à tout l'historique retraçant la génèse de son code.

JL

Ok

Merci à tous pour vos aides et explications. C'est maintenant un peu plus clair dans ma tête.

JC

Le 18/12/2017 à 11:57, JLuc a écrit :

Le 17/12/2017 à 22:48, Jean-Christophe Villeneuve a écrit :

Pas tout compris cette histoire d'historique : puisqu'il existe dans la v3, pourquoi le garder dans la V4 ?

En cas de problème ou d'interrogation,
l'historique permet d'accéder aux diff de chaque commit qui permettent de comprendre,
avec en prime les explications données dans les logs de commits.

Que la branche s'appelle v4 ou v3 ou trunk ou dev ou wtf,
il faut donc pouvoir accéder à tout l'historique retraçant la génèse de son code.

JL

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone