2010-09-08 7 views
1

J'ai un tronc monolithique qui comprend de nombreux projets et leurs modules partagés correspondants. Je souhaite que la base de données soit organisée de manière plus flexible, mais ce n'est pas le cas. Ce que je voudrais faire est de créer une branche qui est une sorte de vue raffinée spécifique au projet du tronc. Vraiment, c'est une étiquette, parce que je veux seulement l'écrire une fois mais je veux seulement marquer des parties choisies de la base de données. Comment puis-je faire cela tout en générant le moins de bruit de validation? De la ligne de commande dans mon espace de travail, je pourrais svn cp les dossiers d'espace de travail au dossier de branche (en sélectionnant seulement les modules particuliers à un projet). Cependant, le tronc est assez gros et il y a potentiellement un très grand nombre d'objets à déplacer. Donc, cela devient rapidement lourd. L'utilisation de svn cp sur l'url du serveur me permet de copier sélectivement chaque chemin vers le dossier branche/étiquette comme bon me semble, mais j'obtiens une opération de validation par copie. Lorsque nos projets sont suffisamment stables, les messages du journal de validation sont généralement utiles pour les gestionnaires de projet, ce niveau de bruit de validation serait donc ennuyeux.Lot 'svn cp' côté serveur

Ce que je voudrais faire est de copier le tronc avec un ensemble de filtres. Ou bien, copiez complètement le tronc puis supprimez les dossiers inutiles (en générant seulement deux messages de validation). Mais, autant que je sache, il n'y a aucun moyen de «supprimer» les copies ou les suppressions sur le serveur. Est-ce correct? D'autres alternatives?

Répondre

0

Je voudrais vérifier le tronc dans un répertoire de travail, probablement en utilisant l'option --depth de sorte que je n'ai pas un grand arbre source (voir http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.checkout.html). Le plus grand avantage de cette approche est que vous pouvez jouer, jeter des erreurs et faire un seul commit.

+0

Je pense que cela fonctionne pour moi. J'ai écrit un script ruby ​​qui vérifie un squelette de mon arbre source (appelé récursivement pour chaque chemin avec '--dept vide'). Ensuite, je peux ramifier sur le squelette. Plus pratique que ce que je pensais. Personne d'autre à mon bureau ne pourrait gérer mon script ruby, donc ce n'est toujours pas idéal. Mais bon, ça marche pour moi. – GlobalReset

0

Le svn manual couvre une section appelée Définitions externes.

Parfois, il est utile de construire une copie de travail qui est faite d'un certain nombre de différentes caisses. Pour l'exemple , vous pouvez vouloir que différents sous-répertoires proviennent de différents emplacements dans un référentiel ou peut-être de différents référentiels .

Peut-être svn: externals est une solution de slik autour de la conception du dépôt limité, vous devez traiter.

+0

ouais, svn: les externes fonctionneraient pour ce que je veux aussi, mais quand je fais une vue de projet, je veux que ce soit "officiel" dans un sens. Créer les externes signifie que je dois les épingler à une révision particulière. Ce qui crée juste un peu plus de maintenance. J'essayais en fait de m'éloigner de cette approche. J'aime aussi la possibilité de parcourir la vue du projet dans le repo-browser, qui ne supporte pas les externes en tant que tels. – GlobalReset

+0

Vous pouvez choisir ou non d'épingler des externes à une révision, donc vous pouvez aller dans les deux sens –

+0

@Sander est correct que vous pouvez choisir de ne pas épingler un externe à une révision, mais méfiez-vous que toutes les branches/étiquettes de ces externes seront TOUJOURS pointez sur la révision HEAD actuelle pour que vous perdiez la vue du monde dans le temps si vous faites cela (ce serait bien si svn copy avait une option pour durcir ces références de révision pour vous). –