Discussion :

[koala01]

hello,

pour ma part j'ai travaillé avec svn,
et ca n'a rien franchement rien à voir avec git,
j'aime les outils rapides!
en plus les branches sont importantes, et svn ne les gere pas bien,
de plus oubliez les merges entre 2 versions!

C'est un avis qui se respecte... Mais

pour ma part, je trouve que la lib part de trop petit, il y a trop d'investissement à faire et vu mon trop peu de temps libre, je préfère utiliser Qt pour arriver à mes fins. En outre, je penche du coté web et j'ai encore beaucoup de choses à explorer (webkit) sans oubliez Quick (et wpf).

Tu comprendra que, même si rien ne t'empêche de donner ton avis, il ne soit pas, disons, prioritaire dans de telles conditions...

Le choix des outils à utiliser dépend essentiellement de l'équipe de dev, ce qui importe au niveau de l'utilisateur, c'est qu'il puisse facilement se procurer l'objet développé, et ca, que ce soit git ou svn (je parle pour les versions stables, compilées ou sous forme de sources), cela revient au final au même: c'est une archive, éventuellement un installateur

D'autant que, comme je l'ai fait remarquer, l'hébergement est demandé, et en instance d'être obtenu.

Définitivement la "farfelue" lib est trop bas niveau pour moi mais je la suivrais

Le fait est qu'il faut bien commencer par quelque chose et que, comme j'ai essayé de le faire transparaitre au cours de la discussion, je n'estimes pas opportun de partir de l'existant pour finir par ne créer qu'une surcouche.

Peut-être réévaluera tu ta position par la suite, une fois que les bases seront correctement posées et que nous attaquerons les aspects plus haut niveau, qui sait

[Lavock]

Ah bon ? Même si git est installé à côté du Redmine ?

Personnellement, je suis peut être lent détente mais :

SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs)

me semble tout a fait clair.

Dans ce cas oui, mais dvp n'as pas prévue de proposer du git...
Donc ça coince

Y a-t-il une once de micro-espoir de les faire changer d'avis ? Je n'ai rien contre l'utilisation de SVN tant que c'est pas à moi de gérer les merges personnellement... Mais pour la santé d'esprit de koala, il y a mieux !


Sinon, c'est peut être sous entendu quelque part, mais pour les inlines :
Je met dans les .h(pp) uniquement celle qui n'implique que des types prédéfinies, histoire de limiter (voir interdire ><) les includes dans les .h(pp).

[Invité]

Une question de béotien (je bosse sous SVN, et je n'ai pas particulièrement de mal avec):

- si on démarre sur SVN, peut on, une fois qu'on a une version stable, c'est à dire à un moment où les "branches" sont mortes, passer sous un autre système? (je crois que oui)
- au démarrage du projet, c'est à dire à un moment ou on a une petite équipe qui écrit beaucoup de code (plutôt que plein de personnes qui font des petites modifs), les avantages des autres systèmes sont ils significatifs? (je crois que non)

Francois

[Alp]

Pourquoi donc, ça ne peut être que mieux que SVN de toute façon ?
(troll facile du matin )

Clairement. Et c'est le seul de tous qui repose sur une théorie solide (la théorie des patchs). Et il est écrit en Haskell

[metagoto]

Clairement. Et c'est le seul de tous qui repose sur une théorie solide (la théorie des patchs). Et il est écrit en Haskell

Oui, j'ai parcouru la doc depuis ton premier post

[koala01]

Une question de béotien (je bosse sous SVN, et je n'ai pas particulièrement de mal avec):

- si on démarre sur SVN, peut on, une fois qu'on a une version stable, c'est à dire à un moment où les "branches" sont mortes, passer sous un autre système? (je crois que oui)

Cela dépend surtout de ce que l'hébergeur propose, ou de la décision d'en changer (d'hébergeur)...

Et je ne sais absolument pas quelle sera la politique de DVP à l'avenir concernant le système de forge...

- au démarrage du projet, c'est à dire à un moment ou on a une petite équipe qui écrit beaucoup de code (plutôt que plein de personnes qui font des petites modifs), les avantages des autres systèmes sont ils significatifs? (je crois que non)

Git est, effectivement beaucoup plus rapide me semble-t-il que SVN lorsqu'il s'agit de récupérer une branche / révision et permet d'avoir des branches partant à peu près "dans tous les sens" si plusieurs commits sont effectués en même temps (me semble-t-il).

Si c'est bien le cas (je ne l'ai utilisé qu'en tant que client en lecture seule), ça devrait avoir l'avantage d'éviter des pertes trop importantes au cas où une modification venait à "tout casser"

[Invité]

Git est, effectivement beaucoup plus rapide me semble-t-il que SVN lorsqu'il s'agit de récupérer une branche / révision et permet d'avoir des branches partant à peu près "dans tous les sens" si plusieurs commits sont effectués en même temps (me semble-t-il).

C'est un peu le genre de situation qui ne devrait apparaitre que quand on commence à avoir quelque chose de montrable... Au début, si on ne se repose que sur le RCS pour garantir la compatibilité de nos commits, le projet est très mal barré, je dirais...

En clair, ca signifie commits réguliers, pas trop de branches, et un peu de coordination à la voix quand on travaille sur les fichiers du coeur (c'est rendu plus simple par l'éclatement des modules en petites unités)

Francois

[koala01]

Je crois en effet que, avec un peu d'organisation et de communication, il est parfaitement possible d'éviter les gros couacs avec SVN...

Reste éventuellement le temps de mise à jour de sa version locale par rapport aux révisions postérieures qui peut demander un peu plus de temps

[Lavock]

Le principale intérêt de git et autre vient de leur décentralisation.

Le problème, c'est qu'avec SVN, on va pouvoir bosser qu'avec une connexion... Or, personnellement, mais "grandes" inspirations arrivent surtout lorsque je suis dans un train par exemple, et que je n'ai rien d'autre à faire (sauf en cas de grève ).

En gros, le but c'est de permettre plus proprement le travail offline [edit] propre (et donc, de pas se retrouver à reporter une idée qu'on a dans le train au lendemain).

[koala01]

Le principale intérêt de git et autre vient de leur décentralisation.

Le problème, c'est qu'avec SVN, on va pouvoir bosser qu'avec une connexion... Or, personnellement, mais "grandes" inspirations arrivent surtout lorsque je suis dans un train par exemple, et que je n'ai rien d'autre à faire (sauf en cas de grève ).

En gros, le but c'est de permettre plus proprement le travail offline (et donc, de pas se retrouver à reporter une idée qu'on a dans le train au lendemain).

Rien ne t'empêche de modifier tes fichiers "quand tu as l'inspiration" et de les transférer sur SVN "quand t'en a la possibilité"...

Tu n'es absolument pas limité quant au nombre de fichiers transférés à chaque commit

Bon, tu as, effectivement, le fait que SVN risque plus facilement de râler du fait que ta version locale est synchronisée avec une révision antérieure à celle du serveur, mais il permet de gérer les incompatibilités

[Lavock]

Et là, on pointe une chose douloureuse...

En gros, une idée => soit je fais ça tout de suite = gros risque de merge immonde + haines des autres devs car commit irrégulier, etc...
Soit je repousse à plus tard... Et en faite, 2 mois plus tard, c'est toujours pas fait -_-'....

[koala01]

Et là, on pointe une chose douloureuse...

En gros, une idée => soit je fais ça tout de suite = gros risque de merge immonde + haines des autres devs car commit irrégulier, etc...
Soit je repousse à plus tard... Et en faite, 2 mois plus tard, c'est toujours pas fait -_-'....

Je présumes que, par "commit irrégulier", tu entends le fait que le commit que tu veux faire se base sur une révision antérieure à celle actuelle présente sur le serveur

De ce point de vue là, je peux te rassurer sur le fait qu'il y a déjà de grandes chances pour que nous assistions à terme à une certaine "spécialisation" au sein de l'équipe.

Dans un tel projet, il ne faudra pas s'étonner de voir que certains préférent travailler sur le look'n feel, d'autre sur l'aspect IHM "bete et méchante" à l'ancienne, d'autres encore sur l'aspect 3D ou RAD ou que sais-je, du fait de leurs affinités dans un domaine particulier.

Le risque de voir deux personnes modifier "chacune de leur coté" le même fichier au même moment reste donc *relativement* limité, d'autant plus que l'accès SVN restera malgré tout limité (les personnes à qui nous y donnerons accès seront "triées sur le volet" )

Au final, si la communication passe correctement, ca devrait bien marcher

Et puis, si on en arrive à quelque chose de *beaucoup* trop gros, tant du point de vue du volume de fichier que du point de vue de la taille de l'équipe, il est toujours possible de réévaluer la décision

[Matthieu Brucher]

Clairement. Et c'est le seul de tous qui repose sur une théorie solide (la théorie des patchs). Et il est écrit en Haskell

Mais bon, il a mal vieilli, c'est un DVCS de première génération !

Je crois en effet que, avec un peu d'organisation et de communication, il est parfaitement possible d'éviter les gros couacs avec SVN...

Effectivement, c'est possible si on reste très propre avec très peu de branches.

Sinon : http://stevelosh.com/blog/2009/08/a-...-in-mercurial/

Rien ne t'empêche de modifier tes fichiers "quand tu as l'inspiration" et de les transférer sur SVN "quand t'en a la possibilité"...

Tu n'es absolument pas limité quant au nombre de fichiers transférés à chaque commit

Tu es juste limité par la propreté et l'atomicité de tes commits

[epsilon68]

un excellent talk de Linus Torvalds sur git:

[Klaim]

Quelqu'un l'a déjà cité, mais je le remet parceque dans la première partie Mr.Spolsky prends le temps d'expliquer pourquoi un DSVC est mieu qu'n truc centralisé type SVN et explique du point de vue de celui qui a toujours utiliser CVS/SVN : http://hginit.com/

Peut être une bonne introduction pour comprendre pourquoi tant de gens ici insistent sur l'utilisation d'autre chose que SVN?

edit> J'en profite pour ajouter : concernant la communication, un forum serait plus utile d'une discussion comme celle-ci...
Cela permettrait par exemple de continuer des discussions en parallèle. Parceque personellement la façon dont le projet va être organisé m'interesse moins que la théorie dérrière le projet et la pratique à l'utilisation. L'organisation est nécessaire mais a un peu perturbé la discussion je trouve.

[Goten]

Ouaip, je plussoie un espace pour discuter. (j'ai une préférence pour les ML, car je trouve ça plus pratique et efficace mais bon...)

[koala01]

j'ai bien compris toutes vos réticences à l'utilisation de SVN, mais voilà...

Je viens de recevoir l'accord pour l'hébergement, et, malheureusement, les choix donnés actuellement CVS ou SVN...

A choisir, je préfère SVN

Maintenant, je vais essayer de voir s'il est vraiment impossible d'envisager, ne serait-ce qu'à terme, l'utilisation de git ou de mercurial... Mais c'est une décision qui ne dépend absolument pas de moi, et je ne pourrai faire mieux que de simplement vous transmettre la réponse.

Comme je l'ai dit, je reste malgré tout ouvert à l'idée de rediscuter de la chose quand l'équipe ou le projet commencera à s'étoffer

[Invité]

Ouaip, je plussoie un espace pour discuter. (j'ai une préférence pour les ML, car je trouve ça plus pratique et efficace mais bon...)

Moi aussi... Maintenant, si on a redmine, c'est assez facile d'y créer un 'forum projet', et de configurer son compte de façon à recevoir les nouveaux messages par email (ou au minimum des notification de ceux ci)

Toujours sur Redmine, sur celui que j'utilise au bureau, Git et Mercurial font apparemment partie de la liste des SCM qu'on peut configurer avec...

Autre chose qui peut être utile, pour tenter "d'acter" les décisions prises en commun sur l'architecture, on peut créer un wiki projet.

Je suggérerais de s'appuyer au maximum sur un petit nombre d'outils, et puisqu'on a redmine... Ce qui me manquerait, aussi, c'est un outil de type chat, à mon avis, avoir la possibilité de discuter de temps en temps, à bâtons rompus, est une bonne chose sur ce genre de projet (même si c'est consommateur de temps)

(edit) sur Git, je continue à penser que ce type de choix devient crucial quand le projet commence à avoir de nombreux contributeurs, qui apportent de "petits bouts décentralisés". Au démarrage, on va plutôt avoir une petite équipe centralisée, je crois. Essayons donc de garder dans un coin de notre tête que ce sera probablement une évolution nécessaire, voyons ce qu'il faudrait pour la préparer (à mon avis, une version stable...), et n'y perdons pas plus de temps...

Francois

[Kalith]

J'ai suivi le post depuis le début, et je trouve l'idée intéressante !
J'ai eu plusieurs fois l'occasion d'intervenir, mais il y a toujours eu quelqu'un de plus rapide pour exprimer mon point de vue...
Je pense en tout cas que c'est bien parti, et je vais continuer à suivre tout ça avec intérêt

Si je me permet d'intervenir maintenant, c'est pour vous déconseiller l'emploi des mailing lists comme unique moyen de communication.
J'ai vu un peu plus haut qu'on citait sinbad (l'auteur de OGRE3D), alors j'en fais de même : click.

Les mailing lists sont sans doute très bien lorsqu'il s'agit de discuter dans un groupe restreint d'habitués. Mais elles sont assez "hostiles" aux petits nouveaux, ou aux invités de passage (c'est grosso modo le contenu du lien ci dessus).

Je n'ai pas envie de lancer un débat sur "pour ou contre les mailing lists" ici, mais je ne saurais trop vous conseiller de mettre en place quelque chose de plus "user friendly", quitte a utiliser une mailing list et un forum (ou autre).

Après, tout dépend de ce que vous voulez faire de cet espace de communication...

[koala01]

Bon, pour être bien clair, je voici ce que nous aurons (laissez juste le temps aux responsables de faire le nécessaire, mais ca devrait arriver assez vite ):

• Un site http://farfelue.developpez.com
• une intégration au gestionnaire de projets projets.developpez.com (yan pourra surement en dire plus que moi sur ce que cela implique)
• un dépot SVN (j'ai posé la quetion à celui qui s'en occupe au sujet de git ou de mercurial, je verrai sa réponse )
• un forum, dans lequel j'ai demandé une section privée dédiée aux développeurs (nous commencerons dans la partie publique le temps de fixer l'équipe )
• Il est possible d'avoir un blog, je ne l'ai pas demandé pour l'instant mais l'option reste ouverte

Pour ce qui est de la possibilité d'un système de chat, je me renseignerai afin de voir s'il est possible d'en créer un directement sur chat.developpez...

Autrement, j'envisage de demander la création d'un salon irc, par exemple,sur oftc

Pour ce qui est du débat SVN Vs git/mercurial, et pour y mettre fin jusqu'à nouvel ordre j'ai bien compris l'ensemble des réticences et des avantages.

Cependant, nous sommes à peine une petite dizaine et il y a encore une série de choses sur lesquelles nous devons nous mettre d'accord avant d'écrire la première ligne de code.

Je crois donc que SVN est amplement suffisant en l'état, et, comme je l'ai déjà indiqué, je n'exclus pas la possibilité d'envisager de passer à autre chose, mais sans doute pas avant que l'on ait le minimum "syndical" qu'est ce que j'ai indiqué comme objectif prioritaire dans le pdf que je vous ai présenté.

J'appuie donc pleinement la dernière phrase deFrançois

sur Git, je continue à penser que ce type de choix devient crucial quand le projet commence à avoir de nombreux contributeurs, qui apportent de "petits bouts décentralisés". Au démarrage, on va plutôt avoir une petite équipe centralisée, je crois. Essayons donc de garder dans un coin de notre tête que ce sera probablement une évolution nécessaire, voyons ce qu'il faudrait pour la préparer (à mon avis, une version stable...), et n'y perdons pas plus de temps...

Pour avancer et "recadrer" un peu les choses, en attendant que l'ensemble soit mis en place, je proposerais de nous intéresser à la conception de la base, d'après ce qui a déjà été exposé jusqu'à présent.

Merci de votre compréhension.