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 NeoX . Évalué à 2.
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 Julien Jorge (site web personnel) . Évalué à 1.
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 benoar . Évalué à 2.
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 Julien Jorge (site web personnel) . Évalué à 1.
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 benoar . Évalué à 2.
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 JoeltheLion (site web personnel) . Évalué à 5.
# merge tracking
Posté par nomorepost . É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 nomorepost . Évalué à 1.
Bon courage
[^] # Re: merge tracking
Posté par nomorepost . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.