Contrôle/gestion de la source de l'implémentation d'un projet open source existant

Question

Je suis actuellement en train d'installer et de configurer un projet open source sur un serveur de test. J'ai été bien formé pour utiliser le contrôle de source, et je veux m'assurer que tout ce que je fais est bien géré (à la fois pour moi, le seul dev/admin, et pour les futurs maintaners). Le projet open source est disponible en téléchargement source ou par svn checkout.

Je souhaite avoir ma propre version contrôlée du projet. Je n'ai pas l'intention de changer le code (servlet java) beaucoup (mais pas du tout), mais il y a des configurations, des fichiers XML, XSL, CSS, etc. tous impliqués que je veux absolument contrôler.

Dois-je aller de l'avant et juste faire mon propre référentiel local de tout le code source? Dois-je essayer de contrôler uniquement les fichiers que j'ai besoin de changer? Dans ce cas, je voudrais que la structure du répertoire corresponde, afin que je puisse faire des extractions directement dans les répertoires de construction.

Answer 1

Avoir deux checkouts à la même arborescence de répertoires ne fonctionnera pas . Si vous extrayez votre source et essayez d'extraire la source du projet OSS, tout répertoire en commun échouera, indiquant qu'il s'agit déjà d'un répertoire de travail pour un projet différent. Si vous pouvez regrouper les fichiers css, xml, xsl etc. dans un répertoire commun, vous pouvez les placer dans un répertoire unique dans le fichier svn de votre propre projet, puis les extraire dans un répertoire du répertoire de travail de l'OSS. projet.

~/travail => svn: // samhoice/projet/trunk

~/travail/osscomponent => svn: // osshost/projet/latesttag

~/travail/osscomponent/config => svn: // samhoice/projet/trunk/config

Dans cette structure, le répertoire osscomponent n'existe pas dans le référentiel svn de samhoice. Il est ajouté par votre script d'installation en tant que racine du répertoire de travail du projet OSS.Le répertoire config n'est pas extrait du projet OSS et n'existe pas dans ce dernier. Le répertoire config est créé par votre script d'installation et le répertoire config est extrait de votre référentiel de projet. Par conséquent, dans cette structure de répertoires, vous avez trois vérifications. Il n'y a pas de chevauchement récursif, donc vous n'avez aucun conflit entre les mappages svn dans les sous-répertoires.

Si vous avez besoin que vos fichiers de configuration soient organisés dans la structure du projet OSS, ajoutez des liens symboliques avec votre script makefile ou config. Vous pouvez aussi probablement le faire dans un crochet post-checkout dans votre client svn.

J'utilise une structure comme celle-ci pour un de mes projets, pour partager du code entre deux arbres de projet. Le contenu partagé est dans un sous-arbre comme je l'ai recommandé pour votre section de configuration.

Answer 2

Je voudrais vérifier tout le code, parce que même si vous ne voulez pas les changer ou ne voyez pas une raison pour le moment, quelqu'un d'autre pourrait voir une raison plus tard. En outre, il pourrait y avoir un bug ou refactoring simple d'améliorer la maintenabilité ou la performance, etc ..

Une mise en page de base pour SVN serait:

branches/ 
tags/ 
trunk/ 

Et la mise en page du répertoire général (sous les trois) devraient Bien sûr, faites correspondre votre application afin de pouvoir la vérifier et l'exécuter immédiatement. Vous pouvez cependant faire de légères modifications à travers un fichier de construction, etc. Mais je suppose que checkout et aller est toujours agréable. Pour plus d'informations, ou des conseils sur les meilleures pratiques, je regarderais d'autres projets opensource en utilisant votre technologie. Comme pour les fichiers de configuration - je ne les vérifierais pas. La plupart des projets vérifient cependant dans un fichier foo-dist qui montre à l'utilisateur toutes les options de configuration. Au minimum, ils doivent copier foo-dist à foo pour activer la configuration par défaut.

En outre, avez-vous regardé Google Code, Sourceforge ou github pour l'hébergement de projet y compris le contrôle de version? Tous les trois vous offrent une tonne, gratuitement - également gratuit en termes que vous n'avez pas besoin de prendre soin d'un serveur pour votre projet d'hébergement, etc.

Answer 3

Je l'ai utilisé plusieurs méthodes, en fonction de la taille et la quantité de personnalisation, le projet 3ème partie:

• Pour les petits ou les projets hautement personnalisés Je vais vérifier la tout, à commencer par le code boursier. Cela facilite le travail sur l'ensemble du projet et fournit un «guichet unique» pour vérifier tout ce dont j'ai besoin pour le construire.

• Pour les grands projets ou légèrement sur mesure, je vais garder une copie de l'archive stock (généralement un fichier .tar.bz2 ou .zip) et assurez-vous qu'il est sauvegardé. Ensuite, je garderai les fichiers qui incorporent mes personnalisations sous contrôle de révision sous une forme quelconque. Les options sont

  • Archivez (seulement) les fichiers personnalisés eux-mêmes. C'est généralement le meilleur choix si vous modifiez le code source.

  • Archivez un script qui effectue la personnalisation. Cela est plus efficace si le script fournit une entrée à un utilitaire de configuration, car vous stockez vos personnalisations (les données d'entrée) séparément des pièces de stock (l'utilitaire de configuration). Si une nouvelle version de la bibliothèque tierce est publiée, il est généralement facile d'y appliquer vos personnalisations, ce qui permet des mises à niveau critiques.

• Pour les projets qui « ne changera jamais ™, » ou pour lesquels les clients ont vous contractuellement lié à des versions particulières, stocker le code de stock quelque part, et créer des fichiers de patch sous contrôle de révision. Ensuite, vous pouvez sortir la version "approuvée" avec un patch. Note: c'est un choix assez horrible, car les fichiers de correctif sont terribles à maintenir - si vous créez un nouveau correctif, vous devez soit recréer les fichiers de correctif, soit créer un correctif supplémentaire appliqué sur le premier correctif. Les raisons du choix de cette option ne sont généralement pas choisies pour des raisons techniques.

Je ne peux pas souligner assez que _Vous besoin de documenter l'ensemble du processus de construction de ce genre de projet et d'ajouter des personnalisations, ou automatiser, ou (de préférence) à la fois. Il est étonnamment facile d'oublier quels fichiers appartiennent où, ou à qui, et il est douloureux de recommencer à zéro. Surtout si vous êtes l'héritier.

Bonne chance!