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 > ?)
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
# merge tracking
Posté par nomorepost . En réponse au message Lenteur de svn merge. É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