Faire face à de gros répertoires dans une caisse

Question

J'essaie de trouver un processus de contrôle de version pour une application Web sur laquelle je travaille. Actuellement, mes principaux obstacles sont deux répertoires qui sont énormes (plus de 4 Go). Seulement quelques personnes ont besoin de travailler sur les choses dans les énormes répertoires; la plupart des gens n'ont même pas besoin de voir ce qu'ils contiennent. Notre structure de répertoire ressemble à quelque chose comme:

/
--file.aspx
--anotherFile.aspx
-/coolThings
---- coolThing.aspx
-/bigFolder
- ---someHugeMovie.mov
---- someHugeSound.mp3
-/anotherBigFolder
----...

Je suis sûr que y ou obtenez l'image.

Il est difficile de justifier une extraction qui doit retirer 8 Go de données qui sont probablement inutiles pour un développeur. Je sais, ce n'est qu'une seule fois, mais même une fois peut être vraiment frustrant pour quelqu'un (et rendra plus difficile pour moi de convaincre tout le monde d'utiliser le contrôle de source). (De plus, les caisses propres seront douloureusement lentes.) Ces dossiers doivent être disponibles dans l'application Web.

Que puis-je faire? J'ai pensé à des référentiels séparés pour les grands dossiers. De cette façon, vous ne téléchargez que si vous en avez besoin; mais alors comment puis-je gérer ces vérifications sur notre serveur de développement? J'ai également pensé à ne pas essayer de contrôler la version de ces dossiers: il suffit de les mettre à jour directement sur le serveur web ... mais je ne suis pas tombé amoureux de cette idée. Y at-il un moyen magique d'exclure simplement les répertoires d'une caisse que je n'ai pas trouvé? (Assez sûr qu'il n'y en a pas.)

Bien sûr, il y a toujours la possibilité d'abandonner, de mordre la balle et d'accepter le téléchargement de 8 Go inutiles.

Que dites-vous? Avez-vous déjà rencontré ce problème? Comment l'avez-vous résolu?

Answer 1

Rien ne dit que la mise en page de subversion doit correspondre à ce que vous déployez en production. Vous choisissez la solution la plus simple et la meilleure - déplacez ces fichiers volumineux vers un autre dépôt (un autre avantage sera que lorsque vous branchez cette structure, vous ne branchez pas non plus les fichiers volumineux). Il vous suffit ensuite de mettre à jour votre script de déploiement pour extraire deux emplacements de référentiel plutôt qu'un seul et placer les fichiers à l'emplacement approprié en production.

Si vous n'avez pas encore de script de déploiement, il est temps d'en écrire un. Même s'il ne contient que deux lignes - les commandes svn à extraire des deux référentiels - il est toujours préférable d'avoir un script qui fait tout en une commande plutôt que d'avoir à le taper à chaque fois. C'est également une bonne idée d'exécuter des tests sur votre contenu avant de redémarrer vos serveurs, afin que ces tests puissent également être intégrés au script de déploiement.

Answer 2

Je ressens votre douleur. J'ai déjà travaillé dans un projet où une caisse était de 20Go. Travailler sur le tronc et trois branches en même temps remplirait ma HD. J'ai détesté.

Vous pourriez diviser cette chose en deux dossiers dans votre dépôt, un ("main") contenant tout ce qui est intéressant pour tout le monde, l'autre ("grand") contenant seulement 8GB de choses que la plupart des gens t soin de. Le "grand" dossier référence "principal" en utilisant des externes.

 
/
-/main 
--file.aspx 
--anotherFile.aspx 
--/coolThings 
----coolThing.aspx 
----... 
-/big 
--/bigFolder 
----someHugeMovie.mov 
----someHugeSound.mp3 
--/anotherBigFolder 
-/everything 

La plupart des gens voudraient simplement vérifier "principal".Certains checkout "grand" et, par le biais de l'extérieur, recevrait "principal", aussi.

Notez que l'utilisation d'éléments externes requiert une attention particulière lors de l'étiquetage, car vous souhaitez associer les éléments externes des versions balisées à une révision spécifique.