Forum général.général Lenteur de svn merge

Posté par (page perso) .
Tags : aucun
1
15
sept.
2009
Bonjour,

Nous utilisons un dépôt svn dans le cadre du développement de notre jeu Plee the Bear. De temps en temps, nous créons une branche le temps d'implémenter une nouvelle fonctionnalité, ce qui me semble assez classique.

Je remarque qu'une opération merge demande de plus en plus de temps, au point que ça en soit exaspérant. J'aimerais savoir ce qui cause cette lenteur et comment y remédier.

Par exemple, j'ai récemment fais cette branche à partir du dossier ''trunk/game''. J'ai modifié divers fichiers dans les trois sous-dossiers puis j'ai fait le merge vers le trunk :svn merge -r 2667:HEAD https://plee-the-bear.svn.sourceforge.net/svnroot/plee-the-b(...) .
Et là, c'est la catastrophe. Il a fallu des heures pour que la fusion se fasse, sans compter les interruptions pour cause de connexion coupée qui m'ont obligé à relancer la commande trois fois (heureusement que ça ne reprend pas du début à chaque fois).

Pourquoi est-ce si long ? Est-ce la faute du logiciel Subversion ? De Sourceforge.net, qui fournit le service et est peut-être débordé ? Est-ce dû à la structure du dépôt et comment devrions-nous l'organiser pour réduire ces temps ?

Et surtout, pourquoi le journal liste de nombreux fichiers avec un simple « props changed » alors que je n'ai fait que quelques petites modifications dans une soixantaine de fichiers ? (des fois ce « props changed » apparaît même sur des fichiers ou dossiers auxquels je n'ai pas touché) [1], [2] et [3].

Quand je regarde le moniteur CPU et le moniteur réseau, je vois que le CPU reste à zéro quasiment durant toute la durée du merge, tandis que les transmissions sur le réseau se font de manière discontinue (je vois une petite pointe à intervalles réguliers). J'imagine donc que le problème vient plutôt de l'autre côté du réseau, mais à tout hasard : la machine sur laquelle je lance la commande est un Duron à 1,3 GHz avec 1 Go de RAM et est connectée en ethernet directement sur la Freebox.
  • # outils et atime

    Posté par . Évalué à 2.

    à tous hasard quand tu modifies tes fichiers tu utilises vim/emacs
    ou un IDE ?

    il se pourrait qu'en ouvrant ton fichier avec l'IDE il charge en memoire les fichiers inclus dans le fichier qui t'interesse.

    du coup le systeme pose un atime (access time) sur le fichier

    svn pense alors que le fichier a etait modifié et le renvoie aussi vers le serveur

    ce n'est qu'une hypothese, mais cela pourrait expliquer pourquoi en modifiant ~60 fichiers
    il en renvoie en fait beaucoup plus

    (il y a peut-etre une option dry-run ou simulate pour voir ce qui va etre fait sans pour tant faire la manip, cela te permettrais de savoir pkoi c'est si long)
    • [^] # Re: outils et atime

      Posté par (page perso) . Évalué à 1.

      à tous hasard quand tu modifies tes fichiers tu utilises vim/emacs
      ou un IDE ?


      J'utilise xemacs pour éditer mes fichiers. À vrai dire, il y a des fichiers qui sont marqués « props changed » qui ne sont absolument pas liés au modifications faites dans la branche.

      Par contre, je viens de remarquer quelque chose en regardant le log de ce fichier [http://plee-the-bear.svn.sourceforge.net/viewvc/plee-the-bea(...)]. J'avais fait la branche à la révision 2667, à partir du trunk. Mais, en révision 2747 j'ai fait un merge du dossier tags/0.4 vers le trunk. Peut-être que c'est le fait de faire ce merge intermédiaire qui fait marquer des « props changed » à svn ?

      Ceci dit, le fichier en question n'a pas été modifié depuis la révision 2499, donc je m'attendais à ce qu'il soit concerné par aucun des deux merge.
  • # FS Microsoft ?

    Posté par . Évalué à 2.

    Tu n'a pas précisé sur quel système tournait ta machine ...
    Je sais que les SVN avec Linux et Windows cohabitant ont parfois des problèmes de permissions qui changent en passant d'un système à l'autre (c'est sûrement du à la gestion des permissions sous NTFS et sous les FS unix). Et puis dans ton cas ce n'est pas facile de diagnostiquer, l'interface web de sourceforge ne permettant pas de voir les "props changed". T'as des messages plus précis ?

    Sinon pour la lenteur générale, sourceforge est connu pour ne pas être ce qu'il y a de plus foudroyant comme service (enfin, c'est une vieille constatation de ma part).
    • [^] # Re: FS Microsoft ?

      Posté par (page perso) . Évalué à 1.

      Tu n'a pas précisé sur quel système tournait ta machine ...

      Sous Linux bien sûr ! Ubuntu même. Par contre je ne sais pas pour Sourceforge.net. Peut-être qu'ils tournent sous Windows… (un serveur svn tournant dans cygwin lancé dans un Windows virtualisé etc.)

      Je n'ai aucun détail pour les « props changed ». Je crois que les fichiers et dossiers pour lesquels c'était indiqué ne sont même jamais apparu dans un commit effectué sur la branche.

      Ceci dit, c'est vrai que l'on a des ralentissements un peu partout sur Sourceforge.net. En particulier sur le wiki, qui met plusieurs minutes à afficher les pages après quelques modifications. On a songé plusieurs fois à migrer, mais on ne sait pas où aller pour être sûrs d'avoir de meilleures performances.
      • [^] # Re: FS Microsoft ?

        Posté par . Évalué à 2.

        OK, ok :-)

        Pour les "props changed", tu les vois lors d'un svn diff. Ce serait utile de savoir ce qui change exactement (genre le bit exécutable, c'est souvent le truc bizarre entre Windows/Linux, bon, ici ça ne sera pas le cas). Franchement, garder un historique avec plein de props changed sans savoir d'où ça vient, je trouve que ça fait dégueulasse.

        Sinon, pour les autres forges, ce n'est pas ma spécialité donc je ne connais pas grand chose à part http://savannah.gnu.org/ ...
  • # Git?

    Posté par (page perso) . Évalué à 5.

    Je ne sais d'où viennent vos problèmes avec svn, mais s'ils persistent, je vous suggère d'essayer git. De l'avis général c'est le gestionnaire de version le plus rapide qui existe (et ma propre expérience le confirme). De plus, la transition depuis svn est facile grâce à git-svn. Vous pouvez même garder le dépôt svn dans un premier temps, puisque git sait se comporter en client svn.
  • # merge tracking

    Posté par . Évalué à 1.


    Et surtout, pourquoi le journal liste de nombreux fichiers avec un simple « props changed » alors que je n'ai fait que quelques petites modifications dans une soixantaine de fichiers ? (des fois ce « props changed » apparait même sur des fichiers ou dossiers auxquels je n'ai pas touché) [1], [2] et [3].


    Bienvenue avec la nouvelle version de SVN qui supporte le merge tracking (Sourceforge est passé à SVN1.5 ou > ?)

    http://blog.red-bean.com/sussman/?p=92
    http://www.collab.net/community/subversion/articles/merge-in(...)

    Le pire c'est que ca n'a rien réglé au pbs de SVN qui est tjs aussi bloated:
    Les merges cycliques sont tjs ingérables
    http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)

    Les renommage/deplacement des fichiers est tjs out
    http://subversion.tigris.org/issues/show_bug.cgi?id=898
    et comme leur archi est complètement foireuse, ils reportent ad vitam eternam cette fonctionnalité "secondaire" (on reporte à la 1.8 parce qu'on est pas foutu de gérér ca dans la 1.7".

    Du coup, si tu fais un refactoring qui déplace un répertoire ou renomme un package dans une branche, que tu modifies des fichiers dans l'autre branche,
    au moment du merge tu perd toutes tes modifs

    Ca encourage vachement l'utilisation des branches.
    Mais les javaistes ont la parade, ils ont eclipse et pour donc refactorer 2X 2 suite c'est top moumoute
    Après fô pas mutliplier les branches parce que ca use quand même, alors ils ont inventé l' "intégration continue" et y bossent tous dans la même branche comme au bon vieux temps de CVS. Fô etre agile qui z'ont dit !

    Dire que dans ma boîte, ils veulent abandonner Clearcase pour c'te daube et que j'arrive pas à les convaincre que hg ou git roxxent les ours

    Allez je te donne un tuyau
    http://mercurial.selenic.com/wiki/WorkingWithSubversion
    http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

    Mais va pas le dire aux étrangers
    Sinon ils viendraient nous la piquer
    http://www.cancoillotte.net/spip.php?article174
    • [^] # Re: merge tracking

      Posté par . Évalué à 1.

      Ah oui j'ai oublié de te dire les prop changed c'est sûrement les svn:mergeinfo que je t'ai refilé dans le 2e lien.

      Bon courage
    • [^] # Re: merge tracking

      Posté par . Évalué à 1.

      Pour t'en sortir tu peux peut-être tenter de récupérer tes 2 répertoires dans un workspace et faire un bon vieux merge 3ways avec des working copies:

      svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]


      Tu passes que des chemins locaux et je pense que ca ne devrait pas communiquer avec le serveur avant le commit
      genre pour merger vers branche2:
      cd /svn/mywc/branches/branch2
      svn merge /svn/mywc/branches/branch1@1223 /svn/mywc/branches/branch1@1845 .


      Tiens nous au courant !

Suivre le flux des commentaires

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