2010-03-15 7 views
4

J'ai vérifié maintenant une copie de travail locale d'une base de code qui vit dans un svn repo. C'est un gros projet Java dans lequel j'utilise Eclipse pour développer. Eclipse construit bien sûr tout à la volée, à sa manière, tous les fichiers binaires se terminant par [projet root]/bin. C'est très bien pour moi, pour le développement, mais quand la construction tourne sur le serveur de construction, ça a l'air assez différent (build maven, les binaires se retrouvent dans une structure de répertoires différente, etc.). Parfois j'ai besoin de recréer l'environnement de serveur de construction sur mon système de développement local pour déboguer la construction ou quoi que ce soit, donc je finis généralement par télécharger une nouvelle copie de travail dans un nouvel espace de travail et exécuter la construction à partir de là (empêche encombrer mon espace de travail de développement avec tous les artefacts de construction et salir la copie de travail). Bien sûr, je suis parfois intéressé par l'exécution de la version complète du code que je ne veux pas encore vérifier, donc je vais copier manuellement l'espace de travail "développement" dans l'espace de travail "build". En plus de prendre beaucoup de temps en copiant beaucoup de fichiers dont je n'ai pas vraiment besoin (juste en superposant le nouveau sur l'ancien), cela dévisse aussi mes méta-données svn, ce qui signifie que je ne peux pas vérifier les changements espace de travail "copie de travail, et je finis souvent par devoir télécharger de nouveau le code pour le remettre dans un état connu. Donc je pense que je vais faire de mon travail svn de travail un repo git local, puis "extraire" le code de développement du svn working copy/git master, dans l'espace de travail local. Ensuite, je peux construire, revenir à mes changements, avoir tous les avantages d'une copie de travail contrôlée par la version dans l'espace de travail de construction. Ensuite, si j'ai besoin d'apporter des modifications à la construction, retournez-les dans le maître git (qui est aussi une copie de travail svn), puis vérifiez-les dans le repo svn principal.Puis-je avoir un espace de travail à la fois un espace de travail git et un espace de travail svn?

|-------------| 
|main svn repo| <------- |---------------------| 
|-------------|   |svn working copy  | <------- |--------------------| 
         | (svn dev workspace/ |   | non-svn-versioned | 
         | git master)  |   | build workspace | 
         |---------------------|   | (git working copy) | 
                  |--------------------| 

commutant tout à git serait évidemment mieux, mais, grande entreprise, trop de gens utilisant svn, trop coûteux pour tout changer, etc. Nous sommes coincés avec svn comme repo principale pour l'instant.

BTW, je sais qu'il existe un plugin maven pour Eclipse et tout, je suis surtout intéressé de savoir s'il existe un moyen de maintenir un espace de travail qui est à la fois une copie de travail git et une copie de travail svn. En fait, tout système de contrôle de version distribué fonctionnerait probablement (hg peut-être?). Conseil? Comment tout le monde gère-t-il cette situation de devoir gérer à la fois un processus de construction «développement» et un processus de construction «production»?

Répondre

1

L'idée de cloner un repo git (copie d'un repo svn) dans un autre repo git peut fonctionner.
Depuis Git1.7.0, vous pouvez associer cette approche à sparse checkout si vous ne voulez pas extraire tout de votre premier dépôt Git.

Questions connexes