[Résolu] De la bonne utilisation de Subversion

Orion Elenion · Le 31/03/2008, à 18:10

Bonjour,

autant le dire tout de suite, le développement dont je m'apprête à parler ne se fait ni sous Ubuntu, ni pour Ubuntu. Il s'agit d'une question générale, et je me tourne vers la communauté Ubuntu-fr pour son importance et sa réactivité.

Mes employeurs tiennent à utiliser Subversion pour gérer le code source d'une site interne en PHP, interfacé avec une base de données MySQL. Or, si l'installation est tout à fait opérationnelle, l'un des développeurs, donc un futur utilisateur de Subversion, m'a fait part d'une remarque intéressante lorsque je lui ai présenté l'outil.

En effet, d'habitude, les développeurs accèdent au code source PHP via un répertoire partagé monté sur leurs postes, le code se trouvant physiquement sur une machine dédiée. Ceci est possible au vu du petit nombre de développeurs : ils ne se gênent généralement pas. Ils font leurs modifications, les enregistrent, puis les testent via un simple rafraîchissement de leur navigateur, le serveur Apache se trouvant sur la même machine que le code source.

En utilisant Subversion, cela les contraint à récupérer le code en local, puis, à chaque modification, à l'envoyer par commit avant de faire un rafraîchissement de leur navigateur.

Est-ce bien la bonne façon de procéder ? Je suis d'accord que c'est très contraignant et ralentissant... De plus, cela génère un nombre important de révisions inutiles dans le référentiel Subversion...

Il existe d'autres solutions, mais aucune ne me satisfait :
- utiliser un serveur Apache propre à chaque développeur, directement sur leur poste : problème pour l'accès à la base de données MySQL, qui n'est autorisé qu'en local ;
- reprendre le principe de l'ancien répertoire partagé où se trouve physiquement le code, mais en ayant un répertoire partagé distinct par développeur : si le problème de l'accès à la base de données ne se pose plus, on a en revanche un nombre ridicule de copies du code source directement sur le serveur, sans compter la nécessité de reconfigurer Apache à chaque arrivée/départ d'un développeur dans l'équipe (en d'autres termes, on réutilise le serveur Apache déjà en place, mais avec un VirtualHost distinct pour chaque développeur).

Quelqu'un voit-il une autre solution ?

Merci d'avance.

Dernière modification par Orion Elenion (Le 11/04/2008, à 19:37)

teke · Le 31/03/2008, à 19:14

Petite réflexion personnelle. Je pense qu'une solution simple à mettre en place serait de prévoir un sous domaine de test sur le serveur (et en accès restreint) ou chaque développeur aurait son dossier...

Pour faire un test, il lui suffit de lancer un script qui synchronise son répertoire de travail avec le répertoire sur le serveur...

Autre solution...
Travailler sur un répertoire en local, et faire un à travers un tunnel ssh vers le serveur pour avoir l'accès à la base de donnée...

Orion Elenion · Le 31/03/2008, à 21:25

Si j'ai bien compris ta première solution, cela revient à avoir une copie du code source par développeur... Le fait que cette copie soit en local ou monté à distance ne change pas grand chose dans ce cas-là puisqu'il s'agit de réutiliser le serveur Apache déjà existant... C'est bien ça ?
Si oui, cela me paraît effectivement la solution la plus simple. Mais elle présente l'inconvénient d'avoir une copie du code source par développeur, en outre, il faudra compléter la configuration Apache à chaque arrivée d'un nouveau développeur...

Quant à la seconde solution, j'ai de toute façon tendance à ne pas apprécier l'idée du serveur local, pour la simple raison que l'environnement n'est pas le même (postes Windows (hélas) et serveur Linux).

Sinon, il reste toujours la solution de faire un commit à chaque fois... C'est bourrin tout de même, non ?
Ou alors... deux référentiels. L'un où il y aura des commits de bourrins systématiques, et un qui soit moins mouvementé et où un commit aura lieu uniquement après un véritable apport. Il faut que je réfléchisse pour voir si c'est envisageable et quel serait le lien entre les deux référentiels.

obiwankennedy · Le 31/03/2008, à 23:15

Subversion n'est pas vraiment fait pour du test et de la sauvegarde.Subversion ne sert que de sauvegarde. Moi, je ferai un dossier partagé sur le serveur (samba ou NFS) avec une copie de travail du site. et chaque soir je "committerai" avec un script "cron" au serveur Subversion.
Comme ça une sauvergarde tous les jours (donc pas 35 par jours). et les 2 activités sont bien séparer d'un coté tu as le dossier de travail (où Apache travaille) et un dépot subversion qui conserve la sauvegarde journalière.

philou8237 · Le 01/04/2008, à 09:02

Subversion te permet qd même d'éviter les conflits. Si deux developpeurs modifient un fichier en meme temps, svn sera capable de faire une jointure propre dans la plupart des cas. Sinon... l'un écrasera le boulot de l'autre...

Deuxième point, avec svn, tu peux facilement revenir à une version précédante et en cas de modification posant un problème, de trouver qui l'a effectuée.

Maintenant c'est à toi de voir si tu souhaite profiter de ce système ou pas, et de peser le pour et le contre.

Martopioche · Le 01/04/2008, à 09:55

Bonjour,

Oulàlà attention... Svn (dont les concepts sont extensibles à Cvs, ou plutôt de Cvs) n'est pas un gestionnaire de sauvegarde !!! C'est un gestionnaire de versions. L'objectif lors de l'utilisation d'un Svn est de pouvoir faire des développements indépendants (chaque développeur développe "dans son coin") et de pouvoir les joindre à la fin. Svn gérera alors les versions (les commits), les mergs si 1 fichier a été modifié par 2 développeurs, la possibilité de revenir sur une version précédente, l'indexation de certaines versions (tags) et les évolutions différentielles de code (branches). Si l'objectif est juste de faire une sauvegarde, n'utilise pas subversion.

Pour répondre à la question première, utiliser Svn va vous nécessiter de revoir vos habitudes de développement. Et désolé de dire ça comme ça, mais à la vue de ce que tu dit, ça vaut mieux... Je m'explique

Dans votre méthode actuelle, il n'y a qu'un seul endroit où sont vos sources et les développeurs vont les modifier de façon anarchique. La conséquence est que il est possible que 2 développeurs interviennent sur les même sources avec la conséquence que l'on connaît. L'autre problème est le contrôle d'intégrité : comment être sûr que chaque mise à jour ne vont pas tout faire planter. Ensuite, vous n'avez aucune possibilité de gérer les versions, le suivi de modifications et les évolutions différentes.

De plus, d'après ce que tu décrit, un développeur fait une modif et la teste sur un code commun. Si 2 devs travaillent sur une partie proche, impossible de savoir à cause de quoi a lieu le plantage.

La bonne pratique est :
- Vous disposez d'un repository Svn qui contient votre code stable.
- Chaque développeur récupère en local le code.
- Lors des développements, le développeur travail sur son code et que sur celui-ci. Il réalise l'intégralité de son développement ou plutôt des pas de développement.
- A chaque pallier stable (classiquement code qui compile, mais sous php disons code qui plante pas le navigateur, et tests qui passent : très important la notion de tests unitaires dans ce cas), alors là le dev fait un update (toujours un update en premier), vérifie que tout est ok, puis fait un commit. Le commit par Cron est une aberration et n'a aucun sens.

Evidemment, cela nécessite d'avoir un apache en local. Pour la base, je ne vois pas pourquoi limiter la base de dev à du local, mais dans ce cas, vous utilisez une mock. Quand au soucis windows/linux, c'est un grand classique mais normalement il ne devrait pas poser un gros problème pour du Php. Si oui, demande au chef de projet de revoir sa copie...

Utiliser Svn demande une très grande discipline et rigueur de travail : respect des règles de versioning et surtout toujours avoir sur Svn une version stable. J'ignore quels sont les outils pour Php, mais pour tirer pleinement parti de Svn, il faudrait coupler celui-ci à un outil d'intégration continue. Dans ce cas, celui-ci se déclenche à chaque commit (en plus de ce qui est paramétré), compile le code pour les langages compilables, et execute les tests unitaires. Si une de ces étapes plante, en général, c'est alerte à tous les niveaux. Si tout est ok, il est même possible de finir par un déploiement.

Donc utiliser Svn n'a que du bon, mais a comme contrainte qu'il nécessite d'avoir une approche très sérieuse et moins geekAWanAgain

nikko · Le 01/04/2008, à 10:07

Tu dois pouvoir continuer à utiliser un serveur distant (où tourne le serveur apache), tout en versionnant via svn. Je ne vois pas de contradictions.

En fait c'est comme ça qu'on travaille à mon boulot :
Nos conteneurs weblogic + les sources sont sur un serveur (SunOs).
On code sous windows via eclipse + partage samba.
On versionne avec cvs (sur le meme serveur SunOs, mais ça pourrait être un autre serveur).
Le fait de tester les développements est complétement indépendant du versionnage de source.

Nikko

Dernière modification par nikko (Le 01/04/2008, à 10:08)

philou8237 · Le 01/04/2008, à 10:23

Après si vous voulez de la sauvegarde... il est toujours possible de dupliquer le disque contenant le repository svn, de manières diverses et variées.

teke · Le 01/04/2008, à 10:30

Orion Elenion a écrit :

Si j'ai bien compris ta première solution, cela revient à avoir une copie du code source par développeur...

Oui de toute façons !!! et SVN est utilisé pour fusionner après un cycle de dv/test...

Orion Elenion a écrit :

Le fait que cette copie soit en local ou monté à distance ne change pas grand chose dans ce cas-là puisqu'il s'agit de réutiliser le serveur Apache déjà existant... C'est bien ça ?

oui effectivement.

Orion Elenion a écrit :

Mais elle présente l'inconvénient d'avoir une copie du code source par développeur, en outre, il faudra compléter la configuration Apache à chaque arrivée d'un nouveau développeur...

Pas besoin... Juste un sous domaine... et chaque dev à un dossier dans ce sous domaine... rien à paramétrer, juste un dossier à créer/supprimer.

Orion Elenion a écrit :

Sinon, il reste toujours la solution de faire un commit à chaque fois... C'est bourrin tout de même, non ?

Non, pas du tout ! et ce serait même la solution que je choisirai personnellement ! En plus, ce qui génial avec SVN c'est que les dev peuvent se créer une branche de développement, pour faire leur test... et une fois que c'est validé il le fusionnent dans le tronc ! Avec en sus la possibilité d'introduire un hooks qui va te faire automatiquement un export dans un dossier du serveur, ce qui permet de tester le code sur place !!!

C'est comme ça que je fonctionne pour plusieurs sites web gérés par plusieurs personnes... sans utiliser de cms ou de php... (des très gros sites déjà anciens...)

Orion Elenion a écrit :

Ou alors... deux référentiels. L'un où il y aura des commits de bourrins systématiques, et un qui soit moins mouvementé et où un commit aura lieu uniquement après un véritable apport. Il faut que je réfléchisse pour voir si c'est envisageable et quel serait le lien entre les deux référentiels.

Dur à gérer...

les dev, après test que leur modif son ok, fusionnent dans devel. L'administrateur, après test que les modif des différents dev ne se gênent pas mutuellement, fusionne dans trunk.

Enfin... c'est juste un exemple... car ensuite svn permet de faire vraiment beaucoup de scénarii différents. C'est là toute sa force d'ailleurs...

ReWinD · Le 01/04/2008, à 10:43

Salut, perso pour ce qui est de SVN, on l'utilise aussi dans notre environnement, et nous n'avons aucun souci à ce niveau.

Si j'ai bien compris, tu aimerais que les utilisateurs puissent vérifier les modifications apportées à la volée ?

Je vais commencer par te répondre que faire de commit à tour de bras n'est pas bourrin puisque c est exactement la raison d être de SVN, c'est comme ça qu il faut travailler et de plus un commit ça prend une seconde si tu laisse rapidSVN ouvert pdt les développements.

Ensuite si l'utilisateur veut voir les modifications qu'il vient de faire il y a 2 soluces :

- La première consiste, comme tu le dis plus haut à avoir chacun un environnement de DEV sur sa machine, ce qui est quand même une bonne chose et n'est pas spécialement plus complex à mettre en place. Nous on travaille comme ça, et on a du windows mac et linux comme machines clientes et tout va nikel.

- la seconde, que nous utilisons aussi avec un developpeur qui aimerait voir ses modifs à la volée, mais un peu plus contraignante pour lui car il doit gérer ses versions entre 2 commits lui même, consiste à placer le code source de ton developpeur sur le même serveur mais dans son répertoire à savoir :

/home/username/public_html/

C'est le système que j'ai mis en place pour ce développeur, à l'aide de samba et SSH je lui ai crée un répertoire partagé auxquel elle peut rester connectée en permance, comme avec un lecteur logique. Mais après faut bien que la personne soit attentive à ce qu'elle fait (genre qu elle mette sur sa version, une couleur de fond différente aux pages web de la version commune des développements pour éviter la confusion.)

Orion Elenion · Le 01/04/2008, à 11:14

obiwankennedy a écrit :

Subversion n'est pas vraiment fait pour du test et de la sauvegarde.Subversion ne sert que de sauvegarde. Moi, je ferai un dossier partagé sur le serveur (samba ou NFS) avec une copie de travail du site. et chaque soir je "committerai" avec un script "cron" au serveur Subversion.
Comme ça une sauvergarde tous les jours (donc pas 35 par jours). et les 2 activités sont bien séparer d'un coté tu as le dossier de travail (où Apache travaille) et un dépot subversion qui conserve la sauvegarde journalière.

Je te remercie de t'être penché sur la question, mais je ne suis vraiment pas d'accord. D'ailleurs, pour répondre aussi à

philou8237 a écrit :

Après si vous voulez de la sauvegarde... il est toujours possible de dupliquer le disque contenant le repository svn, de manières diverses et variées.

, il y a déjà une sauvegarde quotidienne en place.
Subversion est bel et bien présent pour gérer les conflits, et permettre un retour arrière facile, entre autres. J'insiste sur l'aspect retour arrière qui est complètement invalidé avec ta solution, puisqu'un commit par cron ne permet pas de décrire les changements qui ont eu lieu dans une révision, ni donc de rechercher parmi ces descriptions.

Martopioche a écrit :

Pour répondre à la question première, utiliser Svn va vous nécessiter de revoir vos habitudes de développement. Et désolé de dire ça comme ça, mais à la vue de ce que tu dit, ça vaut mieux... Je m'explique
Dans votre méthode actuelle, il n'y a qu'un seul endroit où sont vos sources et les développeurs vont les modifier de façon anarchique. La conséquence est que il est possible que 2 développeurs interviennent sur les même sources avec la conséquence que l'on connaît. L'autre problème est le contrôle d'intégrité : comment être sûr que chaque mise à jour ne vont pas tout faire planter. Ensuite, vous n'avez aucune possibilité de gérer les versions, le suivi de modifications et les évolutions différentes.

Je suis tout à fait d'accord avec toi. D'ailleurs, je n'ai pas été explicite là-dessus, mais personnellement, je ne suis pas chargé du développement sur ce projet. Mon rôle consiste uniquement à mettre en place la solution Subversion. Je m'attache à aller voir chaque développeur et à lui expliquer le fonctionnement de l'outil, répétant à peu de choses près ta "bonne pratique de Subversion".
Pour le reste, je retiens ta solution de l'Apache local, qui me semble intéressante. L'accès à la base MySQL pourra peut-être être étendu à un certain sous-réseau IP, ce qui devrait permettre d'y accéder depuis les postes des développeurs (à voir avec les chefs de projet). Je ne connais pas le terme "mock", de quoi s'agit-il ?

teke a écrit :

Orion Elenion a écrit :
Si j'ai bien compris ta première solution, cela revient à avoir une copie du code source par développeur...
Oui de toute façons !!! et SVN est utilisé pour fusionner après un cycle de dv/test...

Oui, bien sûr, je me suis mal exprimé. J'entendais "une copie du code source par développeur sur le serveur", ce qui me paraît un peu bourrin. Pour l'instant, il n'y a que deux développeurs (d'où, généralement, l'absence de conflit, surtout qu'ils travaillent directement côte-à-côte), mais cela peut changer un jour si le projet prend de l'ampleur.
Ceci dit, j'aime bien ta solution d'une branche par développeur. Subversion travaillant par copies retardées, cela permet d'envisager ce schéma de fonctionnement même pour un grand nombre de développeur... à condition de pouvoir filtrer facilement les commits qui ont eu lieu dans le trunk et ceux qui ont eu lieu dans d'autres branches. Je ne me suis pas encore suffisamment familiarisé avec Subversion (ou plutôt, le client TortoiseSVN qui sera utilisé) pour pouvoir le dire, mais je vais regarder ça sous peu. De plus, cela n'impose pas aux développeurs de remplir leur description de commit à chaque fois, mais uniquement lorsque celle-ci se fera dans le trunk, ce qui est déjà moins contraignant pour eux. Qui plus est, cela ne nécessite pas de modifications au niveau des configurations Apache/MySQL (ce serveur n'étant pas un serveur de production, mais uniquement de développement, le DocumentRoot pourra se trouver à la racine du trunk).
En modifiant légèrement cette solution (effectivement, dans tags se trouvent déjà nos versions stables, donc je pense que chaque développeur peut se permettre un commit directement sur le trunk lorsque la fonctionnalité sur laquelle il travaillait est stable), l'arborescence en question serait donc :

/
|-- trunk   # Version "stable"
|-+ branches   # Différentes versions en cours de développement, où on commit comme des malades.
| |-- dev1   # Branche de travail du développeur 1.
| |-- dev2   # Branche de travail du développeur 2.
|-- tags    # Versions "release".

En revanche, la question de plusieurs copies du code source, toutes présentes sur le serveur, se pose encore avec cette méthode.

ReWinD, je viens de voir ta réponse en rafraîchissant la page, globalement il me semble que cela rejoint ce que je viens de dire...

Merci à tous, je penche plutôt pour la première solution... Qu'en pensez-vous ? (Mais le choix final dépend probablement de mes contraintes propres...)

Dernière modification par Orion Elenion (Le 01/04/2008, à 12:36)

Martopioche · Le 01/04/2008, à 13:02

Rebonjour

Alors en ce qui me concerne, je suis pas pour l'idée de faire des branches par développeur. La raison est que plus on laisse un projet diverger, plus le merge est difficile. Le principe d'un gestionnaire de versions est justement de permettre un développement parallèle (plusieurs développeurs, sur le trunk). Dans la phylosophie SVN, de temps en temps on marque une version du code (les tags)(nous par exemple nous taggons les releases). Si un tag évolue parallèlement au trunk, le tag conduit à une branche (typiquement lorsque le trunk évolue jusqu'à la prochaine release, mais que des correctifs sont appliqués, ces correctifs créent une branche.

Sinon, pour la gestion de l'execution, on sort du contexte Svn, mais bon : j'avais pas pensé à proposer un répertoire partagé du serveur web, et du coup avec la configuration de virtualhosts, vous auriez un seul et unique serveur de dev et tout le monde testerai là dessus. Notre habitude (je suis Java ) est vraiment de déployer nos applis sur notre serveur.

En objet, nous avons l'habitude d'utiliser des mock objects. Il s'agit disons de bouchons (bien que les bouchons sont des stub et les stubs ne sont pas des mocks... voir http://www.martinfowler.com/articles/mocksArentStubs.html). Il s'agit d'objets utilisés lors des phases de test qui répondent de manière attendue. L'idée, si la BD n'est pas accessible et que vous vous orientez vers un déploieemnt des apache en local, c'est de proposer un BD light, avec des valeurs qui veulent rien dire mais cohérentes. En gros lorem ipsum quoi

voila voila.

Orion Elenion · Le 01/04/2008, à 13:58

Cette fois-ci, je ne suis pas tout à fait d'accord avec toi. Même si, effectivement, ton point de vue fait évoluer le mien. Je m'explique.
Concernant le concept d'une branche par développeur, effectivement si l'on raisonne de cette façon, le projet diverge. Mais ces branches sont présentes uniquement pour que les développeurs puissent effectuer différentes modifications, chacun dans leur coin sans perturber le trunk. L'objectif étant d'avoir, en permanence, une version fonctionnelle dans le trunk, même si elle ne correspond pas à une release. Du coup, le merge aura lieu à chaque fois que les développeurs jugeront avoir atteint un état stable dans le cours de leur développement.
Là où mon point de vue évolue, c'est qu'effectivement, suite à tes remarques, il vaut peut-être mieux définir une branche par fonctionnalité, plutôt que par développeur. Cela éviterait d'avoir des branches trop longues, en contrepartie le nombre de branches augmentera avec le temps (bien qu'une fois que la fonctionnalité d'une branche sera opérationnelle, la branche ne devrait plus beaucoup évoluer, ce qui signifie que le nombre de branches actives est limité).
Cette approche sous-entend donc un serveur Apache sur le poste de chaque développeur. Plus j'y pense et plus cette approche me parait la plus simple à mettre en oeuvre.

Surtout qu'après réflexion, le contenu d'un référentiel Subversion ne correspond pas forcément sur le système de fichiers du serveur...

Martopioche · Le 01/04/2008, à 15:03

Orion Elenion a écrit :

Concernant le concept d'une branche par développeur, effectivement si l'on raisonne de cette façon, le projet diverge. Mais ces branches sont présentes uniquement pour que les développeurs puissent effectuer différentes modifications, chacun dans leur coin sans perturber le trunk. L'objectif étant d'avoir, en permanence, une version fonctionnelle dans le trunk, même si elle ne correspond pas à une release. Du coup, le merge aura lieu à chaque fois que les développeurs jugeront avoir atteint un état stable dans le cours de leur développement.

Oulàlà, j'ai dût être soit très mal compris, soit très mauvais dans mon explication car je n'ai jamais pensé ça.

La bonne pratique avec Svn est que justement chacun développe "dans son coin" et réalise des commits sans perturber le trunk. Le maître mot est que le trunk contient toujours des sources fonctionnelles c'est à dire compilable (pour les langages compilés), testés et déployable. Le cas typique est qu'un nouveau développeur qui rejoint le projet réalise son checkout des sources et peut découvrir l'appli (car elle tourne) et peut développer à la suite. Du coup, le cycle de commit pour un développeur est de remonter ce qu'il a de fonctionnel quand c'est stable et testé, même si la fonctionnalité n'est pas finalisée. Un dev qui sera sur une fonctionnalité verticale (de l'IHM à un accès BDD disons) pourra très bien commiter le service sans que la présentation ni l'accès aux données ne soient présentes. Sur ce principe, le trunk n'est pas perturbé. Le trunk ne contient en fait QUE des versions en cours de développement. Les versions livrables, ce sont les tags qui les indique.

Ceci est d'autant plus important que si chaque développeur travaille "dans son coin" et qu'on décide de réaliser un gros merge une fois que chacun a fini, on ne découvre les incohérences et les incompatibilités que très tard. La difficulté est en fait d'avoir un bon cycle de commit afin que les autres aient très tôt ta version, sans pourtant remonter un truc trop "en cours de dev". Quand à ton idée (les devs travaillent sur une branche), elle n'a un réel intérêt que pour le développement d'une fonctionnalité longue qui remet profondément en cause le trunk.

Orion Elenion · Le 01/04/2008, à 15:41

Euh... oui. A moins de m'être, à mon tour, mal exprimé, ou d'avoir mal compris, c'est exactement ce que je voulais dire...

Au fil de mes réflexions, je penche peu à peu pour la solution avec un serveur Apache sur chaque poste de développeur, avec un accès direct à la base MySQL. Cela me semble le plus simple à utiliser et à mettre en oeuvre.

ReWinD · Le 01/04/2008, à 18:07

Oui c'est aussi la solution que notre boîte à adopté exactement pour les mêmes motifs que toi.

Cela dit, pour éviter de mettre un serv. apache sur chaque machine, tu peux éventuellement faire un script qui fera un update du server SVN après chaque commit, et publier sur l intranet ton trunk.

De sorte que le développeur fasse son test, et (ou) revienne à la version précedente en cas de souci.

Orion Elenion · Le 01/04/2008, à 18:45

ReWinD a écrit :

un update du server SVN après chaque commit, et publier sur l intranet ton trunk

Je ne vois pas vraiment ce que tu veux dire... Peux-tu expliciter un peu plus ?
Pour l'instant j'en reste à l'idée où un commit équivaut à un stade "fonctionnel" du code source.

teke · Le 01/04/2008, à 19:17

c'est les fameux hooks dont je parlais plus haut

Martopioche · Le 02/04/2008, à 10:13

ReWinD a écrit :

Cela dit, pour éviter de mettre un serv. apache sur chaque machine, tu peux éventuellement faire un script qui fera un update du server SVN après chaque commit, et publier sur l intranet ton trunk.

Seul problème : tester nécessite un commit, donc commit quasi certain de versions instable, donc trunk instable...

Orion Elenion · Le 02/04/2008, à 10:35

Martopioche a écrit :

ReWinD a écrit :
Cela dit, pour éviter de mettre un serv. apache sur chaque machine, tu peux éventuellement faire un script qui fera un update du server SVN après chaque commit, et publier sur l intranet ton trunk.
Seul problème : tester nécessite un commit, donc commit quasi certain de versions instable, donc trunk instable...

+1

Le Farfadet Spatial · Le 02/04/2008, à 10:53

Salut à tous !

Juste une chose : Orion Elenion, vu l'utilisation que tu veux faire, as-tu jeté un œil aux logiciels de gestions de versions décentralisés tels que Git ou Bazaar (peut-être n'as-tu pas la possibilité d'utiliser un autre outil que SVN) ? C'est beaucoup plus souple, la gestion des branches est plus efficace (et performante) que sous SVN. En plus, c'est souvent plus simple à utiliser.

À bientôt.

Le Farfadet Spatial

Orion Elenion · Le 02/04/2008, à 11:31

Le Farfadet Spatial a écrit :

vu l'utilisation que tu veux faire, as-tu jeté un œil aux logiciels de gestions de versions décentralisés tels que Git ou Bazaar (peut-être n'as-tu pas la possibilité d'utiliser un autre outil que SVN) ? C'est beaucoup plus souple, la gestion des branches est plus efficace (et performante) que sous SVN. En plus, c'est souvent plus simple à utiliser.

Effectivement, je n'ai aucun choix logiciel, juste celui de l'organisation fonctionnelle... Même le client SVN sur les postes Windows est imposé (TortoiseSVN) !

Martopioche · Le 02/04/2008, à 14:03

Orion Elenion a écrit :

Même le client SVN sur les postes Windows est imposé (TortoiseSVN) !

Oui ben là pour une fois qu'on impose les bonnes solutions tu va pas te plaindre Tortoise est le meilleur client SVN qui existe et son seul défaut est d'être limité à Windows.

teke · Le 02/04/2008, à 14:51

Martopioche a écrit :

Oui ben là pour une fois qu'on impose les bonnes solutions tu va pas te plaindre Tortoise est le meilleur client SVN qui existe et son seul défaut est d'être limité à Windows.

Wouai... bof...

Le meilleur client svn reste encore à mon avis svn lui même... serte en ligne de commande, mais le meilleur quand même !!!

s'il est de plus interfacé avec make... wouaouw, c'est du tonnerre !!! on a quelque chose de beaucoup plus léger & rapide. D'autant plus que sur un même projet c'est la plus part du temps les mêmes commandes que l'on passe...

Et ce client fonctionne aussi sous windows. Pour le serveur svn que ce soit n'importe que client qui est utilisé cela ne change rien... que tu travaille avec tortoise ou autre chose, cela n'y change rien.

Martopioche · Le 02/04/2008, à 15:33

Lol

Bah, de toutes manières, n'importe quel client graphique n'est rien d'autre qu'une surcouche graphique sur le client svn lui même. Dans le cas de tortoise, il embarque certes ces commandes, mais fondamentalement, en effet, il ne fait rien de plus que ce que permet la ligne de commandes. En fait, si : il facilite grandement l'utilisation et les automatisations, surtout dans le cas d'un serveur ssh+svn surtout utilisé dans des configurations un peu"spéciales"

Donc en fait, pour répondre au fait que Tortoise est imposé, si les dev peuvent installer ce qu'ils veulent, ils pourront utiliser ce qu'ils veulent

pour make j'en sais rien, mais par contre, svn s'intègre très bien dans des projets gérés par Ant ou Maven. Dans ces cas, en effet, couplé à des outils d'intégration continue, ça fuse

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 31/03/2008, à 18:10

[Résolu] De la bonne utilisation de Subversion

#2 Le 31/03/2008, à 19:14

Re : [Résolu] De la bonne utilisation de Subversion

#3 Le 31/03/2008, à 21:25

Re : [Résolu] De la bonne utilisation de Subversion

#4 Le 31/03/2008, à 23:15

Re : [Résolu] De la bonne utilisation de Subversion

#5 Le 01/04/2008, à 09:02

Re : [Résolu] De la bonne utilisation de Subversion

#6 Le 01/04/2008, à 09:55

Re : [Résolu] De la bonne utilisation de Subversion

#7 Le 01/04/2008, à 10:07

Re : [Résolu] De la bonne utilisation de Subversion

#8 Le 01/04/2008, à 10:23

Re : [Résolu] De la bonne utilisation de Subversion

#9 Le 01/04/2008, à 10:30

Re : [Résolu] De la bonne utilisation de Subversion

#10 Le 01/04/2008, à 10:43

Re : [Résolu] De la bonne utilisation de Subversion

#11 Le 01/04/2008, à 11:14

Re : [Résolu] De la bonne utilisation de Subversion

#12 Le 01/04/2008, à 13:02

Re : [Résolu] De la bonne utilisation de Subversion

#13 Le 01/04/2008, à 13:58

Re : [Résolu] De la bonne utilisation de Subversion

#14 Le 01/04/2008, à 15:03

Re : [Résolu] De la bonne utilisation de Subversion

#15 Le 01/04/2008, à 15:41

Re : [Résolu] De la bonne utilisation de Subversion

#16 Le 01/04/2008, à 18:07

Re : [Résolu] De la bonne utilisation de Subversion

#17 Le 01/04/2008, à 18:45

Re : [Résolu] De la bonne utilisation de Subversion

#18 Le 01/04/2008, à 19:17

Re : [Résolu] De la bonne utilisation de Subversion

#19 Le 02/04/2008, à 10:13

Re : [Résolu] De la bonne utilisation de Subversion

#20 Le 02/04/2008, à 10:35

Re : [Résolu] De la bonne utilisation de Subversion

#21 Le 02/04/2008, à 10:53

Re : [Résolu] De la bonne utilisation de Subversion

#22 Le 02/04/2008, à 11:31

Re : [Résolu] De la bonne utilisation de Subversion

#23 Le 02/04/2008, à 14:03

Re : [Résolu] De la bonne utilisation de Subversion

#24 Le 02/04/2008, à 14:51

Re : [Résolu] De la bonne utilisation de Subversion

#25 Le 02/04/2008, à 15:33

Re : [Résolu] De la bonne utilisation de Subversion

Pied de page des forums