Comment est-ce que je branche un fichier individuel dans SVN?

Question

Le concept de branchement de subversion semble être axé sur la création d'une branche [un] stable de l'ensemble du référentiel sur lequel effectuer le développement. Y a-t-il un mécanisme pour créer des branches de fichiers individuels? Pour un cas d'utilisation, pensez à un fichier d'en-tête commun (* .h) comportant plusieurs implémentations source (* .c) spécifiques à la plate-forme. Ce type de branche est permanent. Toutes ces branches verraient un développement continu avec une fusion occasionnelle de branches croisées. Ceci est en contraste frappant avec les branches de développement stable/stable qui ont généralement une durée de vie limitée.

Je ne le font pas veulent branche du référentiel entier (pas cher ou pas) car elle créerait une quantité déraisonnable d'entretien de fusionner en permanence entre le tronc et toutes les branches. À l'heure actuelle, j'utilise ClearCase, qui a un concept différent de branchement qui rend cela facile. On m'a demandé d'envisager la transition vers SVN mais cette différence de paradigme est importante. Je suis beaucoup plus préoccupé par la possibilité de créer facilement des versions alternatives pour des fichiers individuels que sur des choses comme couper une branche de publication stable.

Answer 1

Malheureusement, je pense que la vraie réponse ici est que ClearCase gère cette situation beaucoup mieux que Subversion. Avec Subversion, vous devez branchez tout, mais ClearCase permet une sorte d'idée de "branche paresseuse" qui signifie que seulement un certain groupe de fichiers sont branchés, le reste suit toujours le tronc (ou la branche que vous spécifiez).

Les autres solutions fournies ici ne fonctionnent pas vraiment comme vous le souhaitez, elles ne font que copier le fichier dans un chemin différent. Maintenant, vous devez faire des choses étranges pour utiliser réellement ce fichier.

Erm, désolé. Ce n'était pas vraiment une très bonne réponse. Mais il n'y a pas de bonne solution avec Subversion. Son modèle est branche et fusionne. Edit: OK, ce qui élargit ce que dit crashmstr. Vous pourriez faire ceci:

svn cp $REP/trunk/file.h $REP/branched_files/file.h 
svn co $REP/trunk 
svn switch $REP/branched_files/file.h file.h 

Mais wow !, est-ce sujet aux erreurs. Chaque fois que vous faites un svn st, vous verrez ceci:

svn st 
    S file.h 

Un peu bruyant cela.Et lorsque vous souhaitez regrouper quelques fichiers ou modules dans un référentiel source de grande taille, cela commence à devenir très compliqué. En fait, il y a probablement un projet décent ici pour simuler quelque chose comme les fichiers branchés de ClearCase avec les propriétés svn et la commutation, en écrivant un wrapper autour du client SVN bog standard pour faire face à tout le désordre.

Answer 2

Une "branche" de Subversion est juste une copie de quelque chose dans votre dépôt. Donc, si vous vouliez ramifier un fichier, vous feriez simplement:

svn copy myfile.c myfile_branch.c 

Answer 3

Une branche dans SVN n'est qu'une copie. Je crois que pour le faire comme vous l'espérez, vous devriez avoir chaque version du fichier dans un répertoire séparé dans le dépôt, et le vérifier dans votre dossier source. C'EST À DIRE. Traitez ce fichier comme un projet distinct.

Answer 4

Vous n'avez pas besoin de ramifier l'intégralité du référentiel. Vous pouvez créer des branches de dossiers dans votre projet (comme un dossier d'inclusion). Comme d'autres l'ont noté, vous pouvez également faire une "copie" d'un seul fichier. Une fois que vous avez une copie d'un fichier ou un dossier, vous "basculez" sur le fichier ou le dossier ramifié pour travailler sur la version de branche.

Si vous créez une des branches séparées dossier dans le référentiel, vous pouvez copier vos fichiers ramifiés il via des commandes côté serveur:

 
svn copy svn://server/project/header.h svn://server/branched_files/header.h 

Ensuite, vous pouvez passer ce fichier à utiliser le chemin du référentiel branches_files

Answer 5

Je ne pense pas qu'il y ait beaucoup de point dans la branche d'un seul fichier? Il n'y a aucun moyen de le tester avec le code de coffre? Vous pouvez prendre un patch à la place si vous souhaitez annuler les modifications et les appliquer plus tard.

Answer 6

Etes-vous sûr que vous avez vraiment besoin de cette fonctionnalité dans votre VCS? Pourquoi ne pas utiliser le préprocesseur C et #ifdef le code dont vous n'avez pas besoin? Ou tout outil similaire.

quelque chose comme:

// foo.h: 
void Foo(); 

// foo_win32.c 
#ifdef _WIN32 
void Foo() 
{ 
    ... 
} 
#endif 

// foo_linux.c 
#ifdef _GNUC 
void Foo() 
{ 
    ... 
} 
#endif 

Parfois, si elle ne correspond pas à droite, alors ce n'est pas la bonne solution.

Answer 7

Voici comment je comprends votre problème. Vous avez l'arbre suivant:

 
time.h 
time.c 

et vous devez diminuer pour plusieurs architectures:

 
time.h is comon 
time.c (for x386), time.c (for ia64), time.c (for alpha),... 

également dans votre VCS actuel, vous pouvez le faire en créant autant de branches de time.c au besoin et lorsque vous extrayez les fichiers du VCS, vous vérifiez automatiquement la dernière heure.h du tronc commun et la dernière heure.c de la branche sur laquelle vous travaillez. Le problème qui vous préoccupe est que si vous utilisez SVN lors de la vérification d'une branche, vous devrez fusionner time.h à partir du tronc très souvent ou risquer de travailler sur un fichier plus ancien (par rapport au tronc) cette quantité de frais généraux ne sont pas acceptables pour vous. Selon la structure de votre code source, il y a peut-être une solution. imaginez que vous avez

 
/
/headers/ 
/headers/test.h 
/source/ 
/source/test.c 

Ensuite, vous pouvez bifurquer/et utiliser la fonction svn:externals pour relier vos têtes à la tête du tronc. Cela ne fonctionne que sur les répertoires et comporte quelques limitations en ce qui concerne le retour à test.h (vous devez aller dans le répertoire d'en-tête pour que cela fonctionne) mais cela pourrait fonctionner.

Answer 8

Une branche de Subversion est exactement ce dont vous parlez. Tous les fichiers sont une copie exacte du tronc, à l'exception de ceux que vous modifiez. C'est la méthodologie "copie bon marché" dont il est question dans le livre SVN. Le seul inconvénient est la nécessité de fusionner le tronc dans la branche de temps en temps pour s'assurer que les changements qui y sont apportés se reflètent dans la branche. Bien sûr, si ces changements ne sont pas souhaités, aucune fusion tronc-> branche ne doit avoir lieu. Un moyen facile de fusionner automatiquement les modifications de troncs (qui simule le paradigme Clear Case) consiste à utiliser un script de hook de pré-validation pour fusionner les modifications de tronc avant la validation (en fait, c'est toujours une bonne stratégie pour éviter la dérive du code).