Ok revoir la doc alors. En resume, pour CVS: - on a 1 Repository. C'est la ou se trouve les fichiers RCS (avec une extension bizarre: ',v') C'est un peu l'equivalent du serveur si tu veux. (pas toujours le cas) [les 'depots' sur ton schema] - les gens qui utilisent CVS on chez eux un 'Sandbox' (ou plus) [reprtoire des postes de travail sur ton schema]. Ce Sandbox (bac-a-sable en anglais) represente les fichiers du repository dans une revision donnee. Chacun peu avoir autant de sandbox qu'il le veux. Le seul tric c'est d'avoir le 'CVSROOT' qui soit correct. (attention aussi aux 'sticky tags' cf. la doc.)
Dans le cas classique d'un projet, on cree un Repository avec 'cvs init -d /cvsroot' par exemple. Et ensuite on utilise les autres commandes avec le CVSROOT qui pointe vers le repository. On se trouve alors dans le sandbox. Si tu veux gerer les droits, sous Unix, il faut creer des groupes et y placer les utilisateurs que tu veux. Pour les CVS externes: Pas de problemes, mais tu as les droits en lecture, pas en ecriture. Tu ne peux donc rien casser. Reste donc a faire un 'cvs update' ou 'cvs checkout' de ces projets (voir la doc du site pour avoir le CVSROOT exacte.) Tu auras donc un sandbox relatif au projet exterieur. Dans la boite ou j'etais avant (IDBSoft) on faisait un 'cvs update' du projet Turbine (jakarta.apache.org) toutes les nuits (man crontab). Tous le monde y avait donc acces en local par la suite. (optimisation de la bande passante) Evidemment il faut faire attention a rester synchrone avec les sources du Master. Si tu veux qu'un changement soit fait, tu doit envoyer un 'cvs diff' au responsable J'espere que ca repond a la question? Didier > -----Original Message----- > From: F�lix Hauri [mailto:[EMAIL PROTECTED]] > Sent: 14 January 2002 16:57 > To: [EMAIL PROTECTED] > Subject: RE: CVS et hi�rarchie > > > Je n'ai pas expliqu� mon sch�ma: > - d�pot ``signifie'' CVS Repository (Il me semble que cela traduit > l'id�e, m'enfin je suis loin d'�tre expert en cvs!) > - les d�pots p1 et p2 sont des projets officiels (p.ex apache et > linux;) auxquel on veut participer mais en tant que simple > contributeur. (pas d'acc�s ssh) > - le d�pot personel est � la charge du chef de projet. > (acc�s direct) > - on ne se loggue pas de l'ext�rieur sur le d�pot > personnel. (intrAnet) > > Le but est essentiellement de travailler en groupe sur une > version, (avec > des �l�ves ou qqch ds l gnr;) sans envahir le cvs officiel > avec les essais > de chaques �l�ves. > > On Mon, 14 Jan 2002, Didier Dubois wrote: > > > Le mieux est de peut-etre se connecter au server CVS en SSH. > > Tu peux ainsi faire une verification suivant les logins (LDAP?) > Ne suis pas s�r de bien te comprendre, mais je crois la r�ponse hors > champs (Par ma faute, jav� ka essplik� avamp ! ;) > > > Si tu veux que plusieurs personnes accedent a un module du > repository > > CVS tu peux les placer dans le meme groupe. > Voui, pour ce qui est de la gestion du d�pot personnel et des > acc�s, c'est > bon:) > > > Si non d'apres ton schema les Depots ca correspond a des > repositories > > CVS? > H�, encore une fois, d�sol�;) > > > Pour rappel dans CVS il y a le "Repository" ou se situe les > sources avec > > historique. (en format RCS) et 1 ou plusieurs "Sandbox" ou les gens > Sandbox k�ss�kssa! > > > travaillent (jouent au sable :-) > Comment!? C'est pas pareil!?? > > > PS: avec CVS c'est toujours bon de retourner sur > cvshome.org de temps a > > autre! > > Allez, j'le r'mets un coup:) > > Soit le sch�ma ci dessous: > ---- > <- INTERNET ||| INTRANET -> > -------------\|/------------- > +---------+ | +------------+ > |d�pot p1 | | +--+ editeur 1 | > |officiel | | | | (n�gre) | > +----+----+ /|\ | +------------+ > | +----|||-+ +---------+ | > +--|firewall|--+ d�pot +--+ +------------+ > | +----|||-+ |personnel| +--+ editeur 2 | > | \|/ +---------+ | | (n�gre) | > | | | +------------+ > +----+----+ | | > |d�pot p2 | | | +------------+ > |officiel | | +--+correcteur 1| > +---------+ | � �chef equipe | > | | +------------+ > | | > | | +------------+ > | +--+chef projet | > | | (n�grier) | > | +------------+ > ---- > > Le chef de projet d�cide quels seront les projets pour > lesquels l'�quipe > va contribuer. Par exemple: prof de classe ou responsable info d'une > entreprise. (Dans de tels cas, l'auteur officiel du correctif sera, > respectivement l'�cole ou l'entreprise, mais cela n'a pas grand'chose > � voir dans le probl�me actuel;) > > 1: Comment installer un projet ext�rieur dans une > arborescence cvs perso > > 2: Comment le chef de projet peut-il renvoyer (commit) le > tout � l'ext. > > Existe-t-il une solution ``standard'' ou sinon je vois bien un truc: > Rapatriement > 1: le chef de projet rapatrie le code ext dans son r�pertoire perso, > 2: sauvegardes des r�pertoires CVS dans chaque niveau et destruction > 3: import normal dans l'arborescence perso > > Edition > 4: travail normal avec l'�quipe (co, add, del, commit) > > Retour > 5: le chef de projet d�cide de sa mise � jour vers le cvs exterieur, > Nettoyage de l'arborescence > 6: sauvegardes des r�ps CVS(perso) dans chaque niveau et destruction > 7: restauration des r�pertoires CVS(ext) dans chaque niveau > 8: commit (exterieur) > > Mais je suppose des probl�mes avec > - les num�ros de version, > - les ajouts/suppressions de fichiers > Entre .6 et .7 un petit script intelligent pourrait �vent. > faire le joint. > > > F�lix Hauri - <[EMAIL PROTECTED]> - http://www.f-hauri.ch > > -- > http://www-internal.alphanet.ch/linux-leman/ avant de poser > une question. Ouais, pour se d�sabonner aussi. > -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se d�sabonner aussi.
