svn renommer le problème

Question

Notre code est C ++ et est géré dans svn. Le développement est avec Visual Studio. Comme vous le savez, Visual Studio C ++ ne respecte pas la casse des noms de fichier et notre code, malheureusement, "exploité". ceci fortement.

Non, nous portons notre application sous Linux + gcc, sensible à la casse . Cela impliquera beaucoup de noms de fichiers et de modifications de fichiers. Nous avions prévu de faire le développement dans une branche séparée.

Il semble que svn rename ait un problème bien connu ( ici et ici ). Y a-t-il un moyen de contourner le problème? Est-ce que git-svn ou svnmerge peuvent aider ici?

Merci Dima

Answer 1

Le problème de sensibilité à la casse ne concerne pas Visual Studio vs. GCC, mais plutôt le système de fichiers. les systèmes de fichiers standard sous Windows et Mac OS X (FAT32 et NTFS pour Windows, HFS + pour Mac OS X) sont insensibles à la casse, mais préservent la casse, alors que les systèmes de fichiers Linux (ext2, ext3 et ext4) sont sensibles à la casse. Je vous suggérerais de renommer vos fichiers en utilisant des minuscules pour tous vos fichiers source, puis de créer une branche et, bien entendu, à l'avenir, d'appliquer une règle stricte consistant à utiliser des minuscules et un ".cpp". extension pour tous les fichiers source C ++ et ".h". pour tous les fichiers d'en-tête. Existe-t-il une quelconque raison pour laquelle vous ne pouvez pas renommer avant la branche?

Answer 2

Git lui-même traite (très bien) le problème des fichiers renommés en fusion (et pas seulement là) en effectuant une recherche heuristique du contenu du fichier et de la similarité de nom de fichier en fonction de la modification du nom . Il n’est pas nécessaire d’avoir des informations sur les renommés saisies comme la solution de suivi des renommés.

Answer 3

Il y a deux questions ici, l'une est la limitation svn sur les renomations et les fusions. À mon avis, une fois que l'on a décidé de se baser sur svn pour un projet, il ne serait pas conseillé de changer de logiciel de contrôle de version au milieu. Je parlais aux autres développeurs et faisais des cycles pour verrouiller tout le projet et renommer.

Dans mon cas, j’ai résolu les problèmes de casse-tête des fichiers d’en-tête avec un simple script Perl: cela corrigera les retours à la ligne et définira les includes en minuscule. La partie commentée corrige les inclus.

#!/usr/bin/perl
use strict;
use warnings;
#
use File::Find;
use File::Copy;

sub wanted
{
    if(  m/\.c$/i || m/\.h$/i ) {
        my $orig = 
 Il y a deux questions ici, l'une est la limitation svn sur les renomations et les fusions. À mon avis, une fois que l'on a décidé de se baser sur svn pour un projet, il ne serait pas conseillé de changer de logiciel de contrôle de version au milieu. Je parlais aux autres développeurs et faisais des cycles pour verrouiller tout le projet et renommer. 

 Dans mon cas, j’ai résolu les problèmes de casse-tête des fichiers d’en-tête avec un simple script Perl: cela corrigera les retours à la ligne et définira les includes en minuscule.
La partie commentée corrige les inclus. 

<*>;
        my $bak = $orig.".bak";
        my $dst = $orig;
        system("fromdos",$orig) == 0 or die "fromdos: $?";
#       open(FH,'<',$orig) or die "open $orig: $!";
#       my @lines;
#       while(my $line = <FH>) {
#           if( $line =~ m/(^#include\s+")([^"]+)(".*)$/ ) {
#               print $line;
#               my $inc = $2;
#               $inc =~ tr/A-Z/a-z/;
#               print "change to:\n";
#               print $1.$inc.$3."\n";
#               print "\n";
#               push @lines, $1 . $inc . $3."\n";
#           } else {
#               push @lines,$line;
#           }
#       }
#       close(FH);
#       #move($orig,$bak) or die "move $orig to $bak: $!";
#       unlink($orig);
#       open(FH, '>', $dst) or die "open $dst: $!";
#       print FH @lines;
#       close(FH);

    }
}

find(\&wanted, ".");

Answer 4

Comme d'autres l'ont dit, le problème initial n'a rien à voir avec les GDS. Pour ce qui est de l’utilisation de git, vous pouvez fusionner git-svn et le repousser dans le dépôt SVN - sachez qu’il s’agit d’une option unique, c’est-à-dire que vous ne devez pas vous attendre à ce que SVN réalise que ce commit était une fusion ou même que les fichiers ont été renommés - vous perdrez l'historique des fichiers à moins que vous ne soyez vraiment prudent.

Comme note latérale à côté de "vraiment prudent" option, le seul moyen de rendre git-svn push correct "changement de nom de fichier". L’information à svn qui semble fonctionner de manière fiable consiste à renommer les fichiers dans git-svn sans changer le contenu de tout , à commettre, puis à modifier les fichiers de votre choix et à effectuer une autre validation. Si vous modifiez le fichier renommé avant de le valider, git-svn sait que le fichier a probablement été déplacé mais ne fait apparemment pas suffisamment confiance à sa propre méthode heuristique pour renvoyer cette information à svn. Il est tout à fait possible que je manque une option magique qui améliore ce travail:)