Le 04 février 2017 à 18:20:38 LGV a écrit :
Avec des solutions de versionning on peut BIEN SUR faire des modifications en parallele sur un meme fichier ! Et il y a des outils pour reconcilier les versions durant les merges : si tu touches des bouts de code differente, ca fusionne tout seul, si tu touches le meme code, tu auras surement un "conflit" qu'il suffit de resoudre a la main en analysant les deux modifications.

Ok donc tu lui conseillerais de faire des merge alors qu'il connait pas tout ce qui est GIT ou SVN? je pense que tu vas le noyer ...

Le 04 février 2017 à 18:20:38 LGV a écrit :

A ma connaissance ça existe pas

Bon, desole, mais tu racontes bcp de n'importe quoi depuis le debut, donc je recommenderais a l'OP d'ignorer tes posts.

Si tu en connais je suis preneur, moi j'en connais pas qui te permette de faire ça en LIVE sur Visual studio

si tu veux pas te faire chier, commence par un simple DROPBOX et à chaque sauvegarde ton fichier va se mettre à jour partout. Mais faudra bien faire attention à sauvegarder et actualiser.

C'est ce qu'on fait déjà avec un MEGA

Bon ben je vais devoir me torturer à nouveau avec Git... merci de vos réponses... SpoilAfficherMasquerEt de m'envoyer à nouveau en enfer

Le 04 février 2017 à 18:24:07 LGV a écrit :

Après travailler à deux sur le même fichier ça existe, c'est s'appelle les "méthodes agiles"

Desole mais encore faux ; c'est de l'extreme-programming, et ca permet de generer un code de production de meilleure qualite. MAIS ca n'a RIEN a voir avec les methodes Agiles, qui sont des frameworks de productions iteratifs pour les projet a forte composante creative.

Pas d'accord avec ça, l'extrême programming est bien une méthode agile qui regroupe plein de choses : pair programming, planning poker, CI/CD, TU/TDD/BDD, etc.

C'est pas une méthode agile au sens "planification" au même sens que scrum (un agiliste me hurlerait dessus là ) mais plus des méthodes d'ingénierie, certes mais ça reste de l'agile. Et ça se couple plutôt bien à scrum.

Je pars en H-S, mais faut jamais oublier que dans "agile" il y a "agile" (:hap:) et que ça implique l'expérimentation et le croisement des idées. "faire du scrum" ou "faire de l'XP" c'est de la théorie, pas de la pratique. Dans la pratique on "prend des bouts de scrum" et/ou on "prend des bouts d'XP" et/ou on "prend des trucs qu'on a lu sur un blog/entendu parler ailleurs" et on applique selon notre besoin, avec le risque que ça ne fonctionne pas, mais avec la chance que ça puisse marcher.

il existe qq solutions experimentales de developpement collaboratif en live ; mais ce sont generalement des plugins qu'au final tres peu de monde utilise : ce n'est tout simplement pas pratique, si on a besoin de ca on prefere du "vrai" extreme-programming. Cela dit on sort completement de la problematique initiale, puisqu'on n'est plus dans le versionning, on est dans l'edition.

alkalinan > toutes mes excuses, j'ai appris qqch car je ne faisais pas rentrer l'xp-prog dans les methodes agiles. Pour avoir verifie en parallele, et tes liens le confirment egalement, c'est pourtant bien le cas au sens strict du terme.

Dans la pratique on "prend des bouts de.."

Ca je suis tout a fait d'accord ! En pratique, aucune methode ne marche parfaitement si appliquee betement a la lettre. Il y a toujours des contraintes que l'organisation ou le projet ne peuvent pas remplir.

Pas d'accord avec ça, l'extrême programming est bien une méthode agile

Effectivement, et je m'excuse aupres de alkalinan dont j'ai denonce le propos alors que j'etais moi-meme dans le tort, m'etant restreint a la "production agile" et non pas au developpement agile en general.

Pour finir de repondre a une question qui etait reste en suspend, un jour j'ai du utiliser un truc qui s'appelait VS Anywhere, qui permet de faire du code collaboratif a distance en temps reel :

https://vs.componentsource.com/product/vs-anywhere-0

Mais apparement le produit n'est plus supporte.

On trouve bien qq autres solutions, mais qui semble bcp moins pros : http://collab.codeplex.com/ donc surement source de soucis

Après débat avec un ami, j'y comprends de moins en moins. Je peux faire quoi exactement ? Mon problème reste le même au final, on peux pas bosser sur un même projet ensemble, on doit chacun créer une solution de notre côté et ensuite tout recoller ou bien ?

L'idee generale est que chacun travaille sur une "copie" du meme projet, et effectue des modifications locales ; l'outils de versioning sert justement a vous aider pour "recoller les morceaux", fusionner les changements, etc. en automatisant ces taches laborieuses.

La version unifiee du projet existe sur le serveur de versioning, et tu synchronises regulierement entre le serveur distant et ta copie locale (pour rendre tes changements accessibles aux autres utilisateurs, et recuperer les leurs).

Ce diagramme montre un cas simple avec 2 utilisateurs et un serveur :
https://git-scm.com/book/en/v2/images/small-team-flow.png

Le 04 février 2017 à 19:07:26 [N]aeso a écrit :
Après débat avec un ami, j'y comprends de moins en moins. Je peux faire quoi exactement ? Mon problème reste le même au final, on peux pas bosser sur un même projet ensemble, on doit chacun créer une solution de notre côté et ensuite tout recoller ou bien ?

Le mieux c'est que tu maitrises l'une des solutions qu'on t'a proposé, comme GIT ou autre. Travailler en même temps sur le même fichier est fortement déconseillé et apparement il existe pas de solution pour faire ça en LIVE.

Tu peux toujours travailler sur le même fichier mais de manière asynchrone, pour le coup c'est pas non plus super simple quand on débute, car il faut plonger dans le monde merveilleux des "merge".

Ce que je fais en général c'est ouvrir un serveur GIT distant et je partage le lien avec mes collaborateurs. Ensuite on passe genre 1 à 3 jours suivant la taille du projet à se repartir les taches de façon bien clair (ça nécessite de bien maitriser le projet de A à Z selon moi)

Ensuite chaqu'un boss de son coté sans avoir besoin des ressources des autres. Quand on finit chacun nos tâches, on fait un premier regrupement et on continu ainsi depuis. Je connais pas ton projet après, peut être que t'as pas besoin de tous ça. mais c'est des bonnes pratiques à prendre 😉

Le 04 février 2017 à 19:21:03 LGV a écrit :
L'idee generale est que chacun travaille sur une "copie" du projet, et effectue des modifications locales ; l'outils de versioning sert justement a vous aider pour "recoller les morceaux", fusionner les changements, etc.

La version unifiee du projet existe sur le serveur de versioning, et tu synchronises regulierement entre le serveur distant et ta copie locale (pour propager tes changements aux autres utilisateurs, et recuperer les leurs).

Ce diagramme montre un cas simple avec 2 utilisateurs et un serveur :
https://git-scm.com/book/en/v2/images/small-team-flow.png

OUI VOILA ! c'est ça que je veux faire !

Et si deux versions d'un seul fichier existe ?

L'avantage ce que c'est tres modulaire, c'est toi qui definit la structure en fonction du projet. Pour un projet avec qq collaborateurs ou les taches sont clairement reparties, un workflow centralise, comme decrit juste au dessus, fait parfaitement l'affaire.

Et c'est le plus simple donc autant commencer par la. Un guide detaille des operations courantes :
https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow

Si un fichier a ete modifie en parallele et que deux versions existent, il y a deux possibilites :
- les modifications sont totalement dissociees (tu as modifie le haut du fichier, ton collegue le bas) : la fusion est automatique
- il y a des recouvrements (vous avez tous les deux touches au meme bout de code) : c'est un conflit. Il faut le resoudre manuellement, via l'outils, en analysant les deux versions pour "ecrire" soi-meme la version fusionnee.

Essayez de travailler sur des petites fonctionnalites aussi dissociees que possible : si tout le monde touche a tout en meme temps, ca devient vite ingerable. Apres ca devient un probleme d'archi logicielle : coupling, modularite, etc. pour permettre justement de travailler en fond sur des systemes entiers, sans affecter les colloraboteurs.

Le 04 février 2017 à 19:23:16 [N]aeso a écrit :

Et si deux versions d'un seul fichier existe ?

C'est pas grave, c'est même tout le principe du versionning . Le tout c'est de faire attention quand tu vas vouloir regrouper les deux fichiers ensemble (le merging). Il faut éviter les conflits de version le plus possible.

Bon Git c'est bon

Visual Studio Online, c'est quoi exactement ?

Le 04 février 2017 à 21:17:56 [N]aeso a écrit :

Visual Studio Online, c'est quoi exactement ?

https://www.youtube.com/watch?v=OVqJJxC9IRU

Le 04 février 2017 à 18:24:07 LGV a écrit :

Après travailler à deux sur le même fichier ça existe, c'est s'appelle les "méthodes agiles"

Desole mais encore faux ; c'est de l'extreme-programming, et ca permet de generer un code de production de meilleure qualite. MAIS ca n'a RIEN a voir avec les methodes Agiles, qui sont des frameworks de productions iteratifs pour les projet a forte composante creative.

Bref, je ne vais pas tout reprendre, il y a trop de non-sens. OP > apprend a utiliser Git, normallement ca s'integre dans VS ou VSCode, ou avec un outil tiers comme SmartGit. Mais surtout COMPREND la philosophie : qu'est-ce qu'une branche, pourquoi je branche, comment je porte des features d'une branche a une autre, etc. Tu as un peu de travail pour etre comfortable avec, mais c'est indispensable.

Nous on appelle ça le "pair programming" et pas "l'extrême programming"

Le 04 février 2017 à 22:27:49 Trac3r a écrit :

Le 04 février 2017 à 18:24:07 LGV a écrit :

Après travailler à deux sur le même fichier ça existe, c'est s'appelle les "méthodes agiles"

Desole mais encore faux ; c'est de l'extreme-programming, et ca permet de generer un code de production de meilleure qualite. MAIS ca n'a RIEN a voir avec les methodes Agiles, qui sont des frameworks de productions iteratifs pour les projet a forte composante creative.

Bref, je ne vais pas tout reprendre, il y a trop de non-sens. OP > apprend a utiliser Git, normallement ca s'integre dans VS ou VSCode, ou avec un outil tiers comme SmartGit. Mais surtout COMPREND la philosophie : qu'est-ce qu'une branche, pourquoi je branche, comment je porte des features d'une branche a une autre, etc. Tu as un peu de travail pour etre comfortable avec, mais c'est indispensable.

Nous on appelle ça le "pair programming" et pas "l'extrême programming"

Le pair programming est une composante de l'extreme programming

Par abus de langage on parle parfois d'extreme programming pour parler de certaines de ses composantes. Ca m'est arrivé d'entendre des gens direr "pair programming" pour en fait parler de TDD ou même de code review (qui sont deux composantes de l'XP)