Subversion marque les fichiers non modifiés comme modifiés

Question

Voici un problème étrange que j'ai rencontré en utilisant Subversion : lors de la fusion d'une branche de développement vers le tronc (ou inversement, d'ailleurs) Subversion marquait beaucoup de fichiers comme modifiés - alors qu'ils n'avaient pas été modifiés.

Voici ce qui se passe :

1. Dans ma branche, j'ai committé 1 fichier modifié
2. Dans le tronc, je fusionne dans ce commit
3. Beaucoup de autre les fichiers et les répertoires sont marqués comme "modifiés" sans avoir été réellement modifiés (pas même les espaces, les fins de ligne, les propriétés ou ce genre de choses).

Techniquement, la validation de ces modifications inchangées ne ferait aucune différence, mais je ne veux pas ajouter de bruit dans mes journaux.

Avez-vous une idée de ce qui peut causer cette nuisance et comment l'éviter ? Puis-je demander à Subversion pourquoi un fichier a été marqué comme modifié, ainsi je saurais si c'est le contenu du fichier, ses propriétés, etc ?

FYI Le client de subversion est de la gamme 1.6.x, le serveur de la gamme 1.5.x. Utilisation d'une combinaison de Versions.app et de la CLI sur Mac OS X Leopard.

Answer 1

Ce qui se passe, c'est qu'une fois qu'un fichier/dossier a un mergeinfo explicite (c'est-à-dire une propriété svn:mergeinfo), chaque fusion subséquente vers une branche mettra à jour ce mergeinfo, même si la branche n'a pas été modifiée. fusion suivante vers la branche mettra à jour ce mergeinfo même si le fichier/dossier même si le fichier/dossier n'est pas lié. Ceci est en effet ennuyeux car cela introduit de plus en plus de de plus en plus d'encombrement dans la liste des changements pour chaque fusion.

Pour éviter cela, ne fusionnez que dans le dossier "Root" de la branche, par exemple "/branches/maintenance2.x". Aucun des fichiers ou dossiers sous "/branches/maintenance2.x" ne devrait alors recevoir mergeinfo. Suivez la méthode conseils de fusion dans le livre svn .

Malheureusement, même si vous fusionnez uniquement dans le dossier "Root" de la branche, des propriétés svn:mergeinfo vides peuvent encore apparaître sur des fichiers et des individuels lorsqu'ils sont copiés, pour indiquer qu'ils n'ont pas reçu la même les mêmes fusions que leurs frères et sœurs.

Si vous fusionnez uniquement à la racine, il est probablement prudent de supprimer le sous-arbre superflu mergeinfo. Une façon de le faire est d'effectuer une suppression récursive de la propriété svn:mergeinfo sur chaque fichier et dossier de la racine de votre projet.

mise à jour : Ceci semble être corrigé dans le SVN 1.7. Extrait des notes de version : modifications de l'information de fusion des sous-arbres réduits .

Answer 2

Le changement se fait dans les propriétés du fichier. Si vous exécutez svn proplist vous verrez beaucoup de mergeinfo entrées. C'est parce que svn suit les fusions dans les propriétés des fichiers. Il s'agit d'une nouvelle fonctionnalité de la version 1.5, qui n'existait donc pas dans les versions antérieures.

Je n'ai jamais complètement compris la raison exacte pour laquelle cela se produit, mais il s'agit d'une fuite de l'implémentation interne. Essayer de la comprendre sans comprendre comment svn est implémenté est, d'après ce que j'ai compris, impossible. Cependant, généralement la cause fondamentale est liée à la fusion des sous-arbres. Par exemple, si vous fusionnez les changements d'un sous-répertoire ou d'un seul fichier, plutôt que la branche ou le tag entier. Afin de suivre ce qui a été fusionné, subversion mettra la balise mergeinfo sur le nœud le plus général, mais apparemment il n'est pas assez intelligent pour le choisir. Vous pouvez résoudre le problème en modifiant manuellement mergeinfo . Il suffit de supprimer la propriété de tous les nœuds situés en dessous de trunk, et de s'assurer que trunk a toutes les révisions fusionnées dans sa section mergeinfo . Bien sûr, cela signifie que vous devez vous assurer que les changements ont effectivement été fusionnés.

Tout cela est plutôt déroutant, mais la bonne nouvelle est que les développeurs de svn ont en fait sont Je travaille à rendre le tout plus fluide.

Answer 3

Il peut s'agir d'un changement de propriété, voire d'une modification automatique de l'attribut svn:mergeinfo. Vous pouvez savoir si c'est une modification de propriété en lançant "svn stat". Si le "M" est dans la première colonne, il s'agit de changements de contenu, s'il est dans la deuxième colonne, il s'agit de changements de propriété.