Dailleurs le developpement de la partie ora10g est en partie base sur ora9i (c'est un fork-cp: cp ora9i ora10g et on repart). Tout comme le so/ora11g est un "fork" de cc021/ora10g. Comment gerer cela correctement ?
Il faut commencer par définir «correctement»!
Du point de vue de ton SCM, ici Subversion, il s'agit essentiellement de se souvenir que ora10g est un fork de ora9i, ce que font (certainement) tous les SCM postérieurs à CVS, notamment SVN. (Avec svn cp …)
Le problème est que le fork est déjà fait, donc la question suivante est «comment importer l'hisotorique dans Subversion?» si cette historique existe! J'ai l'impression que ce n'est pas le cas, la solution suivante serait d'utiliser une sauvegarde antérieure au fork pour créer une historique artificielle qui permettrait de garder trace du fork dans Subversion.
Ceci dit, si deux arbres source sont aussi proches que tu le dis, on peut se poser la question de l'opportunité d'un fork. Il peut il y avoir de meilleurs moyens d'adapter votre logiciel à son environnement, par exemple avec du polymorphisme ou une configuration adaptée: le SCM n'est pas forcément le bon lieu pour régler ce problème.
J'ai vu dans un autre fil que tu répugnais à imposer à tes collaborateurs l'emploi des branches. Je te suis en partie, mais en principe le travail sur les branches n'est pas si difficile que ça — à une exception notable près: les merge, qui sont une opération plus délicate. Tu peux tout de même introduire les branches en désignant un petit nombre de «officiers de merge» qui sont plus à l'aise avec la technique et s'occuperont des merge, au besoin avec l'aide du développeur auteur des modifications.
Ceci dit, même sur un public de gens peu rompus à l'emploi des SCMs, des interfaces graphiques (intégration dans un explorateur de fichier) pour le SCM et un outil pour les merge permet à chacun de se débrouiller de façon honorable — dans cette solution, tu peux garder l'idée des «officiers de merge» qui épauleront leurs collègues en cas de difficultés.
[^] # Re: Un dossier par module
Posté par Michaël (site web personnel) . En réponse au message Du bon usage de svn. Évalué à 3.
Il faut commencer par définir «correctement»!
Du point de vue de ton SCM, ici Subversion, il s'agit essentiellement de se souvenir que ora10g est un fork de ora9i, ce que font (certainement) tous les SCM postérieurs à CVS, notamment SVN. (Avec svn cp …)
Le problème est que le fork est déjà fait, donc la question suivante est «comment importer l'hisotorique dans Subversion?» si cette historique existe! J'ai l'impression que ce n'est pas le cas, la solution suivante serait d'utiliser une sauvegarde antérieure au fork pour créer une historique artificielle qui permettrait de garder trace du fork dans Subversion.
Ceci dit, si deux arbres source sont aussi proches que tu le dis, on peut se poser la question de l'opportunité d'un fork. Il peut il y avoir de meilleurs moyens d'adapter votre logiciel à son environnement, par exemple avec du polymorphisme ou une configuration adaptée: le SCM n'est pas forcément le bon lieu pour régler ce problème.
J'ai vu dans un autre fil que tu répugnais à imposer à tes collaborateurs l'emploi des branches. Je te suis en partie, mais en principe le travail sur les branches n'est pas si difficile que ça — à une exception notable près: les merge, qui sont une opération plus délicate. Tu peux tout de même introduire les branches en désignant un petit nombre de «officiers de merge» qui sont plus à l'aise avec la technique et s'occuperont des merge, au besoin avec l'aide du développeur auteur des modifications.
Ceci dit, même sur un public de gens peu rompus à l'emploi des SCMs, des interfaces graphiques (intégration dans un explorateur de fichier) pour le SCM et un outil pour les merge permet à chacun de se débrouiller de façon honorable — dans cette solution, tu peux garder l'idée des «officiers de merge» qui épauleront leurs collègues en cas de difficultés.