Journal Arch vers Monotone

Posté par  (site web personnel) .
Étiquettes : aucune
0
14
avr.
2005
Suite a l'episode BK sur la LKML, je me suis dit que je pouvais retenter d'utiliser monotone car ça fait maintenant 3ans que j'utilise arch/tla (baz aujourd'hui), et je m'encroute dans mes habitudes.

J'ai donc pour tester le bignou, pris le projet XviD depuis Janvier 2004 que j'ai maintenu dans mes archives arch (dispos sur mon site)

En gros j'ai fait, deux scripts de porc:

Le premier importe la base head de 2004:


#!/bin/sh

# ---- Initial import ----



baz get ed.gomez@free.fr--2004-1/xvidcore--head--0.0--base-0 xvidcore.baz

monotone --db=xvidcore.monotone db init

monotone --db=xvidcore.monotone genkey ed.gomez@free.fr

cd xvidcore.baz

monotone --db=../xvidcore.monotone setup .

baz inventory -s | xargs monotone --db=../xvidcore.monotone add

monotone --db=../xvidcore.monotone --branch=org.xvid.head commit --message="Initial import in monotone"


Le deuxieme permet de mettre a jour vers la revision suivante:


#!/bin/sh



REVISION=$1



baz replay ed.gomez@free.fr--2004-1/xvidcore--head--0.0--patch-${REVISION} | grep -v '{arch}' | grep -v '.arch-ids' | grep -v "^*" > replay.txt



ADDED_FILES=`grep ^A[^/] replay.txt |awk '{print $2}'`

MODIFIED_FILES=`grep ^M replay.txt |awk '{print $2}'`

DELETED_FILES=`grep ^D[^/] replay.txt |awk '{print $2}'`

RENAMED_FILES=`grep ^R replay.txt |awk '{print $2 ":" $4;}'`



for i in ${ADDED_FILES} ; do

        monotone --db=../xvidcore.monotone add ${i}

        echo "A ${i}"

done

for i in ${DELETED_FILES} ; do

        monotone --db=../xvidcore.monotone drop ${i}

        echo "D ${i}"

done

for i in ${RENAMED_FILES} ; do

        ORG_FILE=`echo $i | cut -d ':' -f 1`

        DST_FILE=`echo $i | cut -d ':' -f 2`

        echo "R ${ORG_FILE} => ${DST_FILE}"

        monotone --db=../xvidcore.monotone rename ${ORG_FILE} ${DST_FILE}

done

for i in ${MODIFIED_FILES} ; do

        echo "M ${i}"

done



COMMIT_SUMMARY=` baz log -f -r patch-${REVISION}:patch-${REVISION} |grep ^Summary: | sed s,'^Summary:[[:space:]]*\(.*\)$','\1',`

COMMIT_LOG=`baz log -f -r patch-${REVISION}:patch-${REVISION} | awk 'BEGIN{start=0} /^$/ {start=1;} // { if (start != 0) print;}' | grep -v '==========='`

echo "Summary: ${COMMIT_SUMMARY}" > MT/log

echo >> MT/log

echo "${COMMIT_LOG}" >> MT/log


Puis je m'en suis servi comme ça:


# cd ~/tmp/

# mkdir monotone.test

# cd monotone.test

# import-base.sh

# cd xvidcore.baz

# for i in `seq 1 121` ; do commit-rev.sh ${i} ; monotone --db=../xvidcore.monotone commit ; done

# (edition de commit-rev.sh pour passer sur mon archive 2005)

# baz replay ed.gomez@free.fr--2005-1/xvidcore--head--0.0--base-0

# for i in `seq 1 8` ; do commit-rev.sh ${i} ; monotone --db=../xvidcore.monotone commit ; done


Avis de la transition:
- J'ai pas encore vérifié la cohérence des révisions, je ne sais pas si elles sont équivalentes à celles de arch. Mais les commits ne m'ont pas semblé longuets, donc pour un projet de la taille d'xvid, monotone est utilisable sans souci sur ce point la.
- En deux cuillères a pot, j'ai pu coder un script de migration arch>monotone qui conserve l'historique linéaire d'une branche avec tous les logs messages ! Pas mal, il faudrait cependant faire gaffe au type de changeset dans arch, s'il s'agit d'un merge, il faudrait idéalement importer la branche dont provient le merge avant de merger le patch, et utiliser monotone dans un contexte de merge histoire que l'arbre des révisions monotone ait la meme topologie que celui d'arch.
- J'ai mal aux doigts a force de taper le password de mon certificat monotone et de faire :wq pour valider le log pourtant ecrit dans MT/log...

En gros la 0.18 semble aussi sympa a utiliser que arch/baz, la prise en main est plus simple que celle d'un baz 1.3. Le seul point que je trouve dommage c'est le fait de ne pas pouvoir faire un mirror de sa DB locale sur un serveur tout bête HTTP ou FTP ou SFTP comme le fait arch, la on est obligé de lancer un serveur maison qui permet de synchroniser.

Ah bonne surprise, monotone est plutôt bon à représenter les révisions sous forme compacte, les 130 révisions pèsent 1.5MB pour monotone alors que pour arch sur une partoche ext3, ca pèse 3MB, avec certes une révision en cache pour la continuation 2004->2005.

Enfin voila, ma petite expérience avec monotone... au lieu de troller sur le thread BK, on pourrait donner ici ses expériences dans l'utilisation d'outils SCM décentralisés.

PS: j'ai utilisé bazaar 1.3.1 et monotone 0.18 pour effectuer tout ça

  • # Quelques commentaires

    Posté par  (site web personnel) . Évalué à 2.

    je connais pas trop arch donc ça va être un peu limité:

    J'ai mal aux doigts a force de taper le password de mon certificat monotone

    Tu peux définir un "hook" lua dans ~/.monotonerc
    function get_passphrase(keyid)
    if keyid == "moi@trululu.com" then return "mon_mdp" end
    end

    et de faire :wq pour valider le log pourtant ecrit dans MT/log...

    tu peux passer le log dans la ligne de commande avec l'option --message : il ne te lancera pas d'éditeur.

    monotone est plutôt bon à représenter les révisions sous forme compacte

    Et encore : les données sont en base64 dans la db. Or sqlite3 gère maintentant les BLOB, on pourrait donc y mettre directement les binaires ce qui ferait un gain de place de 25%.

    • [^] # Re: Quelques commentaires

      Posté par  (site web personnel) . Évalué à 2.

      Merci pour les tips. Sinon pour passer le log dans la ligne de commande je suis pas trop d'accord, on peut vite etre farppé par la malediction de la ligne de commande trop longue si jamais tes messages commits sont precis, explicatifs et donc bavent d'informations :-)

      Sinon un coup de "export EDITOR="cat"" pourrait faire l'affaire histoire de voir defiler le commentaire de commit sans l'editer.

      Par contre je me fais toujours pas aux revisions par hash, c'est un peu la misere pour communiquer sur le projet:
      - "Dis Toto, tu as mergé 01f5e9964547da4cb8e9 ?" (un sha1 c'est encore plus long ;-))
      - Ah non, Titi, pas encore, je regle des conflits sur 1e5b6985c9a65f9145de23b.
      - Ok ok, toto, moi je vais prendre une aspirine en tout cas, parler de commit monotone, ca me file la migraine.

      :-)

      Je me moque, mais c'est pas bien serieux comme moquerie.

  • # NG ?

    Posté par  (site web personnel) . Évalué à 2.

    Bazaar et Bazaar-NG c'est deux trucs très différents ou pas ?
    Il me semblait que la socièté Canonical sponsorise Bazaar-NG ce qui est un très bon signe sur le dev futur de cet outil.

    • [^] # Re: NG ?

      Posté par  (site web personnel) . Évalué à 2.

      bazaar est une amelioration de tla, qui se concentre sur l'utilisabilite de l'interface cli et de quelques fondamentaux defecteux de tla, mais il ne vise pas une cassure rapide avec tla.

      bazaar-ng c'est plutot un projet qui part de rien, completement incompatible avec arch/tla. L'objectif est de se baser sur les idees de arch tout en les implementant completement differement afin de ne pas repeter des erreurs de conception aui limite tla aujourd'hui.

      Donc a part le nom, ce sont deux choses tres differentes.

  • # Darcs

    Posté par  (site web personnel) . Évalué à 2.

    J'ai installé Darcs et fait quelques petits essais, et le moins qu'on puisse dire c'est que c'est à la fois d'une simplicité étonnante (concepts très clairs, commandes simples et bien documentées) et semble-t-il assez puissant.

    Pour mes petits essais, tout va bien, mais je serais intéressé par l'expérience de quelqu'un qui a tenté de l'utiliser avec des projets de plus grande envergure. Je ne parle pas du noyau, mais de quelque chose à mi-chemin... Pourquoi pas Xvid ? ;-)

    (Note : Darcs évolue très vite au niveau des performances (dans le bon sens), donc pas la peine de ressasser de vieilles choses, à moins que vous n'ayez une expérience toute fraiche dans ce domaine, bien sûr.)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.