Bonjour ,je cherche un outil qui me permetterai d'uploader des sources de divers programmes (C, delphi et php) et de pouvoir comparer les versions facilement, de savoir qui a changer quoi et de pouvoir revenir en arriere pour certains fichiers  
 
l'ideal serait une espece de framework php deja tout fait qui permette de faire ca, cad une solution 100% web, je n'ai pas trop envie davoir un programme externe (client + serveur) pour pouvoir faire ca. De plus ca me permetterai de modifier le soft au besoin....
 
je n'ai pas besoin d'un mastodonte, plus c simple mieux ca ira...
 
je suppose que bcp dentre vous utilisent ce genre d'outils au taf ou autre, donc au lieu de chercher comme un fou pendant des heures je me suis dit que cetait mieux de demander avant (ps : ici c pour le taf aussi)

Subversion
sous Windows tu utilises tortoiseSVN comme client qui s'intègre parfaitement bien  l'explorateur de fichiers.
 
Après je pense pas que tu puisse trouver ce que tu cherches exactement.  
Mais dans ce cas, utilise un wiki

Disons que si tu cherches qqch qui tourne pas client/serveur ... je vois pas trop ..
Moi je te conseille aussi subversion .. je l'utilise depuis quelques mois et j'en suis satisfait à 200%. Tu peux installer le serveur et après, si tu trouves pas un client qui te plait / qui fait ce que tu veux, tu peux toujours t'en écrire un ... Si ce que tu fais est assez ciblé ça reste assez basique, et vu que probablement tu veux l'utiliser sur ton ordio, tu pourrais même le faire en php

darcs

Mais sinon, +1 pour Subversion, très bien et largement meilleur que CVS, facile à installer et bien documenté en plus

merci pour toutes ces reponses
 
enfait je me suis peut etre mal exprimé , quand j'ai dit non client/serveur je voulais dire sans quil y ait besoin dinstaller un tas de programmes juste pour pouvoir aller consulter les sources , qqch daccessible de partout, meme chose pour le serveur, pas besoin de passer 2 jours a installer et configurer le prog a coup de .conf avant davoir qqchose qui marche
 
bon pour le moment je vais regarder dun peu plus pres ce "subversion" pour voir ce que ca donne

Subversion cay bon mangez en.
Pis si tu veux pas un client spécial, subversion ya moyen de mettre ca en Webdav...

Bon j'ai installé le subversion + tortoise... je suis surpris ca marche plutot bien et ca reste assez simple a mon gout
cependant jai encore qq questions:
 
- a quoi sert le svn:// j'ai cru comprendre que ca permettait dacceder a un projet par le reseau , mais apparament ca n'a rien avoir avec le browser ?? ou le browser peut il lui aussi en tirer qqchose?
 
- quel est la difference entre un update et un commit ??? apparament le concept ici cest : tout le monde travaille sur ca copie locale ,puis "valide" cest fichier une fois terminé, cest bien ca? le "vrai" projet etant sauvé dans c:\sub_depot\trunk  et les version intermerdiaires +difs dans des fichiers binaires geres par subversion?
EDIT : bon apparament update permet de recuperer la derniere version et commit de lenvoyer
 
- si par exemple je modifie une dizaine de fichiers c pour mon projet , faut til que je fasse un update /commit pour chaque apres ? ou je peut submitter direct tout le rep et subversion detectera tout seul ce qui a changé?  
EDIT :apparament  il trouve les changement tout seul comme un grand
 
- cest quoi cette histoire de branch / trunk , rien compris
 
j'ai utilisé le tuto ici http://ericreboisson.developpez.co [...] ubversion/
si qqn a un bon tuto sur subversion (pas linstall,les bases, lutilisation) ca minteresse fortemement

Ca permet au client svn d'accéder au repository via le protocole SVN, aucun rapport avec ton navigateur. Par contre tu peux aussi installer apache + mod_dav_svn (et les configurer) pour que ton client puisse utiliser HTTP, et dans ce cas tu pourras te ballader dans ton repository avec ton navigateur.
 
Après il y a des logiciels qui permettent de faire des trucs plus avancés depuis son navigateur genre ViewVC.

Ce sont très précisément les opérations opposées: un commit permet d'envoyer tes modifications locales au repository (afin de les sauvegarder et de permettre aux gens bossant avec toi de pouvoir les voir), un update permet de télécharger dans ta working copy les modications stockées dans le repository (de synchroniser ta working copy avec le repository).
 
À noter que tu peux avoir des modifications dans ta working copy quand tu fais un update, elles seront sauvegardées.
 

Pas exactement. Tout le monde travaille sur sa working copy (sa copie locale, d'un autre côté on ne peut pas bosser sur autre chose), et quand une "unité de travail" (qui différe d'une boite à l'autre et d'un individu à l'autre) est terminée on commit afin d'envoyer les modifications au repository central (et, comme je l'ai déjà dit, de sauvegarder ces modifications et les rendre disponibles pour les autres développeurs)

Oui et non, le repository stocke ce qu'on peut appeler la version "officielle" (la seule qui soit visible en dehors de la machine du ou des développeurs), ainsi naturellement que les informations de versionings, et il effectue la synchro entre les devs

Tu peux commiter tout ce que tu veux, svn est un grand garçon.
 
Par contre la question est de savoir si tu veux vraiment tout commiter. Habituellement j'essaie de suivre ces règles quand je commit:

• Un commit doit concerner -- si possible -- une seule et unique "action" au maximum (correction d'un bug, ajout d'une fonctionalité, correction de typos, réindentation, ...)
• Si un commit concerne une sous-action (on ne commite pas une action complète -- parce qu'on a pas encore fini par exemple mais qu'on veut sauvegarder le point où on en est -- mais uniquement une partie de cette action), le commit ne doit pas casser le trunk: le commit ne doit ni empêcher de compiler le projet, ni empêcher les tests de passer, ni empêcher de faire tourner le projet (c'est extrèmement important, sinon on peut empêcher les autres de travailler)
• Cette règle étant également vraie pour le commit d'une action complète: le repository doit toujours contenir du code compilable (le passage des tests étant un problème différent, on peut vouloir du code ne passant pas certains tests, mais autant éviter)
• On doit pouvoir trouver un nom (une description) claire et non-ambigue pour chaque commit. Ca peut être long dans certains cas, mais ça doit toujours être clair et lister une seule et unique action. Les fichiers impactés ne doivent jamais être listés dans la description (il est trivial de les récupérer via un svn log)
• Tout commit doit se voir associé une description et cette description doit naturellement décrire le contenu du commit/de la révision (pas de "pouet", "bleh" ou "je sais pas quoi mettre alors je mets rien" )

Tu verras ça plus tard

Intro to Subversion Screencast sur ClickableBliss pour la base, puis Version Control with Subversion pour des trucs plus avancés (le bouquin est un peu long, mais toute personne voulant utiliser SVN correctement devrait le lire au moins une fois, au moins du chapitre 1 au chapitre 3 (le 4 est sur les branches et tags, et les chapitres 5 et + sont sur l'admin du repository et le scripting)

merci pour tes reponses rapides, cest bcp plus clair maintenant    
 
ya encore deux ou 3 choses qui me chiffonnent :
EDIT : jai vu la video c bon maitenant pour la partie "conflit"
 
 
 jai 4 projets a gerer (2 en delphi, 1 php et 1 en C)
 
je fait comment ? je cree un depository dans lequel je met 4 branches ????
ou faut que je fasse 4 depository ?(arg)
 
les fichiers autre que les fichiers sources (ressources, ico & co ) et exe compilés doivent aussi rentrer dans subversion?
 
(pour les branch /trunk jai trouve un peu dinfo la dessus, ca c bon maintenant mais faudrait encore tester)

Les "branches" svn ne sont que des conventions, mais ça a un sens bien précis.  
 
Donc non.
 
Tu crées simplement les répertoires correspondants à la racine de ton repository, avec dans chacun un répertoire trunk (pour le trunk), un répertoire branches et un répertoire tags (tous les deux vides jusqu'à ce que tu comprennes bien à quoi ça sert et comment ça fonctionne)
 
e.g.

et quand tu bosses sur un projet tu ne checkout qu'une partie du repository (e.g. svn co svn://repository/projet_c_1)

les fichiers compilés ne doivent JAMAIS aller dans subversion!
 
Dans SVN on ne met aucun fichier généré, on met uniquement ce qui permet la génération e.g. sources, scripts de builds (makefiles), resources (images, ...).
 
On ne met ni les fichiers générés automatiquement (à moins de ne pas pouvoir les régénérer du tout) ni les fichiers compilés (qui sont générés de toute façon).
 
Ja.
Mais.

Laisse tomber pour le moment, apprends déjà à correctement utiliser SVN, les branches ne sont absolument pas nécessaires dans un premier temps (les tags sont plus intéressants btw)

salut,    
ca va bcp mieux avec SVN, cest vraiment un super outil !
j'ai encore une petite question:
 
sur le serveur ou est installé SVN, j'ai egalement 3 site webs php... mon idée serait de pouvoir les modifiers a distance puis de faire un commit et que ca mette automatiquement les site a jour (qui pour le moment sont dans apache / htdocs htdocs2 ,...) mais je n'ai aucune idée de comment faire ca

Les déploiements auto au commit c'est un peu tricky, il faut passer par les triggers SVN (oncommit toussa, cf le SVN Redbook sur le sujet), et si tu déploies direct en prod tu peux balancer des bugs en prod sans avoir pris le temps de les tester.

Le plus simple reste probablement du déploiement timé via cron.

enfait on risque pas trop de probleme pour les bugs en prod, je texplique
 
on a 2 serveurs :
 
studio developpement                                                                                                        domaine situé tres loin
---------------------                                                                                                        ----------------------
-serveurB                                                                           <-------------------------->    serveurA (principal ) (apache ,SQL Server, svn, ftp,....)
(replication du serveurA,  (fichier php+db)                                                ligne internet
sert principalement pour le dev)
               ^
               |
               v
-machine de developement( dont mon pc en loccurence)
 
 
 
donc tout est teste en interne avant de balancer le code

bon petite question
 
j'ai creer un repertoire a laide de svn mkdir
 
si je n'ai plus besoin de ce projet est til possible de le supprimer (sans retirer tout le depository?)

oui, il suffit de svn rm sur le répertoire que tu veux supprimer.
 
Le truc sympa, c'est que l'historique de ton répertoire reste, donc si t'as besoin de le récupérer un jour tu peux

mais ca prend pas de la place????? genre si je veux vraiment le supprimer (historique compris) (bon je c le but de svn est de tout logger)

OSEF de ça

Faut faire ça manuellement avec un export puis un reload de tout le repository, et t'as 9 chances sur 10 de flinguer le truc.
 
Aucun intérêt