Bonjour,
je finis un graduat en cours du soir et l'on a un projet a faire e commun en c, de plus je suis toujours en transballotage entre chez moi et ma copine, alors pour faciliter le developpement entre nous et entre moi-meme je me demandais si un serveur CVS n'arrangerait pas toute l'affaire, je sais que en cherchant sur le net je peux tout trouver mais je dois me focaliser sur le dev, le Cvs c'est du bonus disons.
 
Alors l'idée que je m'en fais:
- installation d'un serveur CVS: a priori sur une machine virtuelle en debian
- a partir de ce moment la il faut un ide gérant le cvs? on le déclare via des parametres de connexion et il retrouve ses jeunes? plus spécifiquement pour le c en avez vous un a me conseiller?
- lorsque l'on compile avec cette methode, la compilation se fait bien sur le serveur?
- d'autre part, est ce que cela permet une synchro avec quelqu'un ayant travaillé offline?
 
merci de votre aide

Aucun rapport avec le langage C...

Cette machine doit être bien réelle... Par virtuelle, tu veux dire un espace à toi sur un serveur chez un hébergeur tiers ?

wxDev C++ sait faire ça. Par contre, la configuration, c'est un peu ardu, je ne pourrais pas t'aider.

Pas du tout. Le serveur sert à maintenir les sources. La compilation est locale.

Non.

Voilà comment ça se passe en réel.

On suppose qu'un repository est installé sur un serveur CVS et que les utilisateurs on configuré leurs clients CVS correctement.

On doit commencer par sauvegarder une version stable et compilable (c'est préférable) des sources sur le serveur.

Ensuite, avant de travailler, chaque utilisateur doit charger chez lui la dernière version des sources (update)
- Si on avait rien : les fichiers sont crées
- Si les fichiers existaient, ils sont vérifiés :
-- pas de changement : rien
-- différences, tentative de fusion.
--- si il n'y a pas de conflit : le fichier est a jour. Il contient les modifications externes et locales
--- sinon, un commentaire est ajouté dans le fichier invitant le codeur à choisir quelle est la bonne version et le fichier est marqué "en conflit". Une fois le conflit résolu, on refait un 'update' de contrôle.

Dès qu'on a une version locale stable, on la sauvegarde sur le serveur (commit) accompagné d'un commentaire 'utile'. (Pas la peine d'écrire 3000 fois 'mise à jour', on s'en doute).

Si plusieurs personnes travaillent en même temps sur le projet, il faut faire des 'update' régulièrement (avant chaque compilation, par exemple). Il faut aussi éviter les conflits, c'est à dire que 2 personnes travaillent en même temps sur le même fichier (le risque est grand sur les petits projets comprenant peu de fichiers. Il faut planifier les tâches de chacun). Si néanmoins un conflit survient, il faut le régler au plus vite.

Noter qu'il est possible de 'poser un tag' (un étiquette) sur une version donnée, ce qui permet un retour en arrière facile.

Noter aussi que chaque fichier a un numéro de version individuel attribué automatiquement à chaque 'commit' , et qu'il est possible de ressortir n'importe quelle version d'un fichier.

Pour finir, le client CVS intégré à wxDev-C++ permet les manips basiques (update/commit), mais pour les manips avancées, je recommande un client CVS complet comme WinCVS (Windows).

Ca simplifierait pas mal l'affaire (ça ou un serveur Subversion, je préfère subversion perso)

Qu'entends tu par "machine virtuelle"? Un virtual host chez ton hébergeur? En tout cas ça doit être une machine "réelle" dans le sens "pas une VM" (pas de VMWare ou autre).

Non, CVS (et Subversion/svn) est un outil indépendant. Le client de base est en ligne de commande, on trouve également des clients "graphiques" indépendants, ou s'intégrant à ton explorateur (sous Windows, TortoiseCVS/TortoiseSVN), et certains IDEs intègrent un client CVS/SVN, soit directement soit sous la forme d'un plugin à installer. Mais ce n'est en rien obligatoire.

C'est à la fois plus simple et plus compliqué que ça, voir en dessous

CVS et SVN sont faits pour travailler sur des fichiers texte, donc très bien pour le C, ou n'importe quel autre langage d prog.

Non, CVS et SVN servent uniquement à garder ton code (le texte, pas les binaires) au chaud.

Oui et non, uniquement si cette personne a utilisé CVS (ou SVN si tu bosses avec SVN) pour créer sa copie locale

Comment travailler avec CVS ou SVN?
Premièrement, si tu n'as pas trop de problèmes avec l'anglais, je te conseille d'aller regarder le screencast Introduction to Subversion chez ClickableBliss
Tu peux également trouver des tutos très corrects sur CVS

Je vais parler de SVN parce que c'est ce que je connais le mieux, mais tout s'applique à CVS (les commandes exactes sont probablement différentes, mais l'esprit est le même)

Comment , donc, utliser SVN. Premièrement, il faut installer un serveur (SVN accessible de tous les endroits d'où tu voudras coder. Le principe, c'est que tu vas stocker ton code dans ce serveur, et ensuite tu synchroniseras régulièrement chacun des clients (les machines sur lesquelles tu développes) avec ton serveur.

Donc tu as installé ton serveur SVN (que j'appellerais par la suite "repository" ), et tu veux commencer à développer. Commences par créer le répertoire de ton projet, puis importe le (avec svn import). De cette manière, tu vas copier ton code dans ton repository.

Maintenant, supprimes ton répertoire local et crée une "Working Copy" (la Working Copy est une copie locale du code placé dans le repository. C'est avec elle que tu interragis, et ensuite tu effectues des synchronisations entre ta WC et ton repository). Par la suite tu créeras une working copy par projet sur chacune des machines sur lesquelles tu veux travailler. La création de la WC s'effectue via 'svn checkout'. 'svn checkout' va aller chercher tous les fichiers demandés sur le serveur, va les placer sur ta machine là où tu l'as demandé, et va les mettre sous la surveillance de svn.

Maintenant tu peux commencer à travailler (créer des fichiers, les éditer, ... comme si SVN n'existait pas). Si à un moment tu veux savoir ce que tu as fait dans ta working copy, tu peux faire un "svn status" pour avoir le status de ta working copy (quels fichiers ont été modifiés ou supprimés, quels fichiers sont inconnus, quels fichiers ont été ajoutés, ...)

Note: quand tu veux ajouter un fichier, le créer ne suffit pas, il faut également dire à Subversion de commencer à le surveiller (avec "svn add", qui ajoute le fichier à la working copy).

Quand tu as fait les modifications que tu voulais faire, tu effectues un "svn commit". On effectue normalement un commit quand on a terminé une "unité de travail" c'est à dire quand on a rempli un objectif (aussi petit qu'il soit, le but étant qu'on puisse l'expliquer dans le message de log sans prendre 15 pages). "svn commit" va synchroniser le serveur avec la working copy, c'est à dire qu'il va envoyer tes modifications locales (fichier ajoutés via SVN ADD, fichiers supprimés via SVN RM, fichiers déplacés/renommés via SVN RENAME, fichiers copiés via SVN COPY, fichiers modifiés par édition, ...) au serveur. Note que ta working copy conserve l'adresse du repository, donc à partir du moment où tu as effectué ton checkout tu n'as plus besoin de re-rentrer l'adresse du repo, SVN est capable de le retrouver sans ton aide.

L'autre opération de synchronisation est SVN UPDATE, qui va synchroniser ta working copy avec le serveur, c'est à dire qu'il va rappatrier toutes les modifications enregistrées sur le serveur das ta copie locale du projet. C'est l'opération que tu effectueras dès que tu arriveras chez toi après avoir bossé de chez ta copine, ou en arrivant chez ta copine après avoir bossé de chez toi. SVN UPDATE a également comme rôle de résoudre les conflits: SVN et CVS permettant autant de working copies que voulu et ne posant pas de lock, il est possible pour plusieurs personnes de modifier le même fichier en même temps (ça ne devrait pas t'arriver dans la mesure où tu es seul à bosser sur tes projets).

Quand celà arrive, il se passe une opération en 4 temps: la première personne commit ses changements. La 2e (qui a modifié le même fichier) tente également de commiter, mais SVN détecte qu'elle vient de modifier un fichier modifié par quelqu'un d'autre (sa copie locale n'est plus synchronisée avec le serveur). La 2e personne doit donc effectuer un UPDATE afin de resynchroniser sa copie locale.

SVN va détecter quel fichier est modifié à la fois sur le serveur et sur la copie locale et va tenter de résoudre le conflit (merge). Si il y arrive, la 2e personne peut commiter, sinon SVN demande à l'utilisateur de "résoudre le conflit", c'est à dire qu'il faut aller éditer le fichier en conflit et le modifier pour garder les modifications qu'on veut sans rien casser. Puis on marque le conflit comme résolu, et on peut commiter.

Maintenant tu voulais savoir si ça permet de travailler avec quelqu'un qui a bossé offline.

Oui à condition que la personne ait travaillé sur une working copy (créée avec SVN CHECKOUT ou CVS CHECKOUT), mais si la personne a travaillé pendant longtemps offline (sans se synchroniser avec le serveur, genre une ou deux semaines) alors il est probable que vous ayez énormément de conflits à résoudre, et vous passerez pas mal de temps là dessus, puis sur la résolution des bugs créés par des merges ratés.

C'est franchement pas idéal. (il y a d'autres outils qui gèrent le versioning offline mieux que CVS ou SVN, mais ils sont notablement plus complexes à manipuler)

its teh mighty paté

Il y à même des ressources en français pour CVS :
 
-> Tutoriel CVS
 
-> La F.A.Q CVS

   
 
La prochaine fois, je double la taille histoire de parler de Darcs

sinon en mode non-connecté il y a mercurial, qui permet par exemple de faire des commits sans avoir accès au dépôt. Pratique quand on a pas l'accès au net on l'on code.

oué ya aussi Darcs, Git, Bazaar-NG, Monotone, Arch/ArX, Codeville, SVK, ...
 
Ce sont tous des Distributed VCS, et ils sont notablement plus difficiles à comprendre que les CVCS, autant commencer avec un CVCS

merci a tous pour vos réponses,
alors je me suis tourné vers SVN finalement et j'ai configuré eclipse sur le repository que j'accede en svn+ssh , ce qui ne fut pas vraiment une mince affaire, +/- 4 heures a batailler pour l'install du serveur + la config du client pour me rendre compte que je devais double backslasher un chemin...
 
sinon le serveur tourne sur une machine debian en virtual pc.
 
merci de votre aide en tout cas, j'ai lu les commentaires attentivement et cela m'a permis de me faire une idée plus nette du systeme