- Le refactoring de répertoire doit pouvoir fonctionner a peu pres correctement (avec un svn move ou un truc du genre, du coup pour ce problème, ça vient d'un défaut de svn dont je vais reparler, mais pas forcément de la ligne de commande, plutôt des interfaces qui se greffent dessus), néanmoins essais dans Eclipse, Nautilus ou un Explorateur windows d'aller dans un répertoire contenant lui même plein de sous répertoires qui sont eux meme committé. Tu fais un couper-coller pour le mettre dans un autre répertoire quelconque lui même déjà sous SVN.
Là, c'est le drame : tu te payes pleins d'erreurs pas possibles, voire parfois si tu commit un fichier dans un sous repertoire de cette arboresence, j'ai l'impression que tu commit tout ça à l'acncien endroit.
Pourquoi ? c'est simple. A l'instar de cvs, svn, créé un répertoire .svn dans chaque répertoire contenant les informations sur le répertoire courant, et l'endroit où il se trouve dans l'arborescence du projet, avec notre copier-coller, on a gardé ce répertoire, qui contient désormais les anciennes informations de où se trouve nos répertoire, pas de bol c'est faux.
Du coup si vous voulez committer l'arbo à la nouvelle place, il ne vous reste plus qu'a vous supprimer tous les ".svn" de tous les sous répertoires. Enfin bon, la fois d'après vous aurez été plus malin, et vous ferez directement un svn export ou un svn move, mais l'action naturelle ne fonctionne pas, et tous les nouveaux de ma boite se font piéger systématiquement.
En comparaison, les hg, git ou bzr ont bien un equivalent du ".svn", sauf qu'il n'y en a qu'à la racine du checkout(donc un copier-coller n'embarque pas des information invalides), et ils retrouvent leur bébé même après avoir déplacé un fichier, en retrouvant tout seul son historique (je suppose que ca se base sur un hash des fichiers pour les retrouver, mais j'ai pas verifié). Bref, ils font juste ce qu'ils doivent faire.
A common desire is to refactor source code, especially in Java-based software projects. Files and directories are shuffled around and renamed, often causing great disruption to everyone working on the project. Sounds like a perfect case to use a branch, doesn't it? Just create a branch, shuffle things around, then merge the branch back to the trunk, right?
Alas, this scenario doesn't work so well right now, and is considered one of Subversion's current weak spots. The problem is that Subversion's update command isn't as robust as it should be, particularly when dealing with copy and move operations.
When you use svn copy to duplicate a file, the repository remembers where the new file came from, but it fails to transmit that information to the client which is running svn update or svn merge. Instead of telling the client, "Copy that file you already have to this new location", it instead sends down an entirely new file. This can lead to problems, especially because the same thing happens with renamed files. A lesser-known fact about Subversion is that it lacks "true renames"—the svn move command is nothing more than an aggregation of svn copy and svn delete.
Dans les faits : créé une branche pour pouvoir réorganiser tes fichiers, déplace les (même avec un svn move et pas un copier-coller, ça change rien sauf le problème des .svn) puis commit dans ta branche, renommes en certains, puis commit dans ta branche, après corrige les chemins qu'il y a dans les fichiers (ça peut être les noms de package en java, ou le chemin relatif vers un répertoire), puis commit.dans ta branche.
Vu que tu a créé une branche, c'est parce que faire ce boulot et corriger tous les fichiers devait te prendre au moins 2-3 jours pendant lesquels tu ne pouvais bloquer les développements de tes collègues, donc qu'on fai tes collègues pendant ce temps ? Ils ont bossé sur les même fichiers que toi dans l'ancienne arborescence. Là on se dit, c'est pas grave, SVN va comprendre que j'ai déplacé, renommé les fichiers en question et me proposera de merger mes changements avec ceux de mes collègues.
Alors là tu te mets à regarder comment faire ton merge, et déjà, t'y comprends rien parce qu'il faut utiliser la version n-1 de ton développement pour le merge, et mettre des référence sur quel est l'origine de la branche et quel et la version avec laquelle on veut merger.
Et là, tu tombes dans ce cas :
For example, suppose that while working on your private branch, you rename integer.c to whole.c. Effectively you've created a new file in your branch that is a copy of the original file, and deleted the original file. Meanwhile, back on trunk, Sally has committed some improvements to integer.c. Now you decide to merge your branch to the trunk:
This doesn't look so bad at first glance, but it's also probably not what you or Sally expected. The merge operation has deleted the latest version of integer.c file (the one containing Sally's latest changes), and blindly added your new whole.c file—which is a duplicate of the older version of integer.c. The net effect is that merging your "rename" to the branch has removed Sally's recent changes from the latest revision!
This isn't true data-loss; Sally's changes are still in the repository's history, but it may not be immediately obvious that this has happened. The moral of this story is that until Subversion improves, be very careful about merging copies and renames from one branch to another.
Bref, dans certains cas, le merge gueule pas (enfin ça, c'est rare) et il vire juste les changements que tes collègues ont fait... Mais bon c'est pas tout :
To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.
So how do we use svn merge in this scenario? Remember that this command compares two trees, and applies the differences to a working copy. So to receive the changes, you need to have a working copy of the trunk. We'll assume that either you still have your original one lying around (fully updated), or that you recently checked out a fresh working copy of /calc/trunk.
But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user! Since svn merge operates like svn diff, comparing the latest trunk and branch trees will not merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the removal of trunk changes that never happened on your branch.
Bon, par manque de temps(je dois partir au boulot), je vais te laisser lire la suite du redbook pour voir tous les problème qu'on se prend dans la gueule avec SVN. Mais pour résumer, c'est pas naturel, pas pratique, ça marche mal, et grossomodo il faut te faire les merges de fichier déplacé, renommés et retravaillé de chaque côté entièrement à la main, merci SVN...
Pendant ce temps là, tu prend un DVCS (bzr, hg ou git, mais me parlez pas de svk). Eux, par nature, comme on doit toujours pouvoir merger 2 repositories facilement sont obligé de gérer correctement ces merge avec déplacement / renommage /modification de fichier. en bref, ça se fait tout seul, et si jamais il y a un conflit entre le 2 code, seul les lignes impactée sont présentées par l'interface de merge, même si les fichiers n'ont rien à voir et ne sont plus du tout au même endroit. Le DVCS fait son job et retrouve l'historique des modifications pour permettre de faire le merge, bref, exactement ce qu'on lui demande.
Merger une branche avec le tronc (représentant 3-4 jours de travaille elle même) dans svn sur un projet conséuqent bloque les developpement de tout le monde pendant 1/2 journée pour le merge voire 1 journée, de plus vous aurez probablement quelques régressions fonctionnelles sur le code developpé sur le tronc, et il vous faudra tout revérifier derrière. Je suis désolé mais je trouve ça minable, surtout quand un hg, bzr ou git règle ca en 5 minute pour le même travaille. C'est tellement vrai que je connais des gens qui font les merge de branche sur svn via git parce que ça leur fait gagner beaucoup de temps.
Il parait que svn 1.5 doit arranger pleins de choses, néanmoins pour moi il est tellement à côté de la plaque au niveau de mes besoins quotidiens que je n'ai même pas envie de lire la doc de la super interface pas logique qu'ils ont du nous pondre pour gérer ça (le coup de la version n-1 à noter sur un papier pour un merge ... Ca mérite un coup de boule pour celui qui a pensé à un truc aussi pas logique par rapport a l'utilisateur, je pense qu'à la prochaine version il devrait prendre prendre 1+sqrt(5)/2 fois le numerio de version arrondi au dessus, ce serait moins pratique encore).
[^] # Re: SVN c'est has been :)
Posté par Temsa . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 4.
- Le refactoring de répertoire doit pouvoir fonctionner a peu pres correctement (avec un svn move ou un truc du genre, du coup pour ce problème, ça vient d'un défaut de svn dont je vais reparler, mais pas forcément de la ligne de commande, plutôt des interfaces qui se greffent dessus), néanmoins essais dans Eclipse, Nautilus ou un Explorateur windows d'aller dans un répertoire contenant lui même plein de sous répertoires qui sont eux meme committé. Tu fais un couper-coller pour le mettre dans un autre répertoire quelconque lui même déjà sous SVN.
Là, c'est le drame : tu te payes pleins d'erreurs pas possibles, voire parfois si tu commit un fichier dans un sous repertoire de cette arboresence, j'ai l'impression que tu commit tout ça à l'acncien endroit.
Pourquoi ? c'est simple. A l'instar de cvs, svn, créé un répertoire .svn dans chaque répertoire contenant les informations sur le répertoire courant, et l'endroit où il se trouve dans l'arborescence du projet, avec notre copier-coller, on a gardé ce répertoire, qui contient désormais les anciennes informations de où se trouve nos répertoire, pas de bol c'est faux.
Du coup si vous voulez committer l'arbo à la nouvelle place, il ne vous reste plus qu'a vous supprimer tous les ".svn" de tous les sous répertoires. Enfin bon, la fois d'après vous aurez été plus malin, et vous ferez directement un svn export ou un svn move, mais l'action naturelle ne fonctionne pas, et tous les nouveaux de ma boite se font piéger systématiquement.
En comparaison, les hg, git ou bzr ont bien un equivalent du ".svn", sauf qu'il n'y en a qu'à la racine du checkout(donc un copier-coller n'embarque pas des information invalides), et ils retrouvent leur bébé même après avoir déplacé un fichier, en retrouvant tout seul son historique (je suppose que ca se base sur un hash des fichiers pour les retrouver, mais j'ai pas verifié). Bref, ils font juste ce qu'ils doivent faire.
- 2e point, les merge avec des refactoring: Là je citerai le redbook SVN ( http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.branchm(...) ) :
A common desire is to refactor source code, especially in Java-based software projects. Files and directories are shuffled around and renamed, often causing great disruption to everyone working on the project. Sounds like a perfect case to use a branch, doesn't it? Just create a branch, shuffle things around, then merge the branch back to the trunk, right?
Alas, this scenario doesn't work so well right now, and is considered one of Subversion's current weak spots. The problem is that Subversion's update command isn't as robust as it should be, particularly when dealing with copy and move operations.
When you use svn copy to duplicate a file, the repository remembers where the new file came from, but it fails to transmit that information to the client which is running svn update or svn merge. Instead of telling the client, "Copy that file you already have to this new location", it instead sends down an entirely new file. This can lead to problems, especially because the same thing happens with renamed files. A lesser-known fact about Subversion is that it lacks "true renames"—the svn move command is nothing more than an aggregation of svn copy and svn delete.
Dans les faits : créé une branche pour pouvoir réorganiser tes fichiers, déplace les (même avec un svn move et pas un copier-coller, ça change rien sauf le problème des .svn) puis commit dans ta branche, renommes en certains, puis commit dans ta branche, après corrige les chemins qu'il y a dans les fichiers (ça peut être les noms de package en java, ou le chemin relatif vers un répertoire), puis commit.dans ta branche.
Vu que tu a créé une branche, c'est parce que faire ce boulot et corriger tous les fichiers devait te prendre au moins 2-3 jours pendant lesquels tu ne pouvais bloquer les développements de tes collègues, donc qu'on fai tes collègues pendant ce temps ? Ils ont bossé sur les même fichiers que toi dans l'ancienne arborescence. Là on se dit, c'est pas grave, SVN va comprendre que j'ai déplacé, renommé les fichiers en question et me proposera de merger mes changements avec ceux de mes collègues.
Alors là tu te mets à regarder comment faire ton merge, et déjà, t'y comprends rien parce qu'il faut utiliser la version n-1 de ton développement pour le merge, et mettre des référence sur quel est l'origine de la branche et quel et la version avec laquelle on veut merger.
Et là, tu tombes dans ce cas :
For example, suppose that while working on your private branch, you rename integer.c to whole.c. Effectively you've created a new file in your branch that is a copy of the original file, and deleted the original file. Meanwhile, back on trunk, Sally has committed some improvements to integer.c. Now you decide to merge your branch to the trunk:
$ cd calc/trunk
$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
D integer.c
A whole.c
This doesn't look so bad at first glance, but it's also probably not what you or Sally expected. The merge operation has deleted the latest version of integer.c file (the one containing Sally's latest changes), and blindly added your new whole.c file—which is a duplicate of the older version of integer.c. The net effect is that merging your "rename" to the branch has removed Sally's recent changes from the latest revision!
This isn't true data-loss; Sally's changes are still in the repository's history, but it may not be immediately obvious that this has happened. The moral of this story is that until Subversion improves, be very careful about merging copies and renames from one branch to another.
Bref, dans certains cas, le merge gueule pas (enfin ça, c'est rare) et il vire juste les changements que tes collègues ont fait... Mais bon c'est pas tout :
To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.
So how do we use svn merge in this scenario? Remember that this command compares two trees, and applies the differences to a working copy. So to receive the changes, you need to have a working copy of the trunk. We'll assume that either you still have your original one lying around (fully updated), or that you recently checked out a fresh working copy of /calc/trunk.
But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user! Since svn merge operates like svn diff, comparing the latest trunk and branch trees will not merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the removal of trunk changes that never happened on your branch.
Bon, par manque de temps(je dois partir au boulot), je vais te laisser lire la suite du redbook pour voir tous les problème qu'on se prend dans la gueule avec SVN. Mais pour résumer, c'est pas naturel, pas pratique, ça marche mal, et grossomodo il faut te faire les merges de fichier déplacé, renommés et retravaillé de chaque côté entièrement à la main, merci SVN...
Pendant ce temps là, tu prend un DVCS (bzr, hg ou git, mais me parlez pas de svk). Eux, par nature, comme on doit toujours pouvoir merger 2 repositories facilement sont obligé de gérer correctement ces merge avec déplacement / renommage /modification de fichier. en bref, ça se fait tout seul, et si jamais il y a un conflit entre le 2 code, seul les lignes impactée sont présentées par l'interface de merge, même si les fichiers n'ont rien à voir et ne sont plus du tout au même endroit. Le DVCS fait son job et retrouve l'historique des modifications pour permettre de faire le merge, bref, exactement ce qu'on lui demande.
Merger une branche avec le tronc (représentant 3-4 jours de travaille elle même) dans svn sur un projet conséuqent bloque les developpement de tout le monde pendant 1/2 journée pour le merge voire 1 journée, de plus vous aurez probablement quelques régressions fonctionnelles sur le code developpé sur le tronc, et il vous faudra tout revérifier derrière. Je suis désolé mais je trouve ça minable, surtout quand un hg, bzr ou git règle ca en 5 minute pour le même travaille. C'est tellement vrai que je connais des gens qui font les merge de branche sur svn via git parce que ça leur fait gagner beaucoup de temps.
Il parait que svn 1.5 doit arranger pleins de choses, néanmoins pour moi il est tellement à côté de la plaque au niveau de mes besoins quotidiens que je n'ai même pas envie de lire la doc de la super interface pas logique qu'ils ont du nous pondre pour gérer ça (le coup de la version n-1 à noter sur un papier pour un merge ... Ca mérite un coup de boule pour celui qui a pensé à un truc aussi pas logique par rapport a l'utilisateur, je pense qu'à la prochaine version il devrait prendre prendre 1+sqrt(5)/2 fois le numerio de version arrondi au dessus, ce serait moins pratique encore).