git-cvsserver - Online în cloud

PROGRAM:

NUME

git-cvsserver - Un emulator de server CVS pentru Git

REZUMAT

SSH:

export CVS_SERVER="git cvserver"
cvs -d :ext:user@server/path/repo.git co

pserver (/etc/inetd.conf):

cvspserver flux tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

Utilizare:

git-cvserver [opțiuni] [pserver|server] [ ...]

OPŢIUNI

Toate aceste opțiuni, evident, au sens doar dacă sunt impuse de partea serverului. Ei au fost
implementat pentru a se asemăna cu git-daemon(1) opțiuni cât mai aproape posibil.

--base-path
Adăugați cale la CVSROOT solicitat

--cale-strict
Nu permiteți recursul în subdirectoare

--export-toate
Nu verificați gitcvs.enabled în config. De asemenea, trebuie să specificați o listă de permise
directoare (vezi mai jos) dacă doriți să utilizați această opțiune.

-V, --versiune
Tipăriți informațiile despre versiune și ieșiți

-h, -H, --ajutor
Imprimați informațiile de utilizare și ieșiți


Puteți specifica o listă de directoare permise. Dacă nu sunt date directoare, toate sunt
permis. Aceasta este o restricție suplimentară, accesul gitcvs trebuie încă activat de
opțiunea de configurare gitcvs.enabled, cu excepția cazului în care --export-toate a fost dat, de asemenea.

DESCRIERE

Această aplicație este un strat de emulare CVS pentru Git.

Este extrem de funcțional. Cu toate acestea, nu toate metodele sunt implementate și pentru acele metode
care sunt implementate, nu toate comutatoarele sunt implementate.

Testarea a fost efectuată folosind atât clientul CLI CVS, cât și pluginul Eclipse CVS. Cel mai
funcționalitatea funcționează bine cu ambii acești clienți.

LIMITAREA

Clienții CVS nu pot eticheta, ramifica sau efectua îmbinări Git.

git-cvserver mapează ramurile Git la modulele CVS. Acest lucru este foarte diferit de ceea ce majoritatea CVS-ului
utilizatorii s-ar aștepta deoarece în CVS modulele reprezintă de obicei unul sau mai multe directoare.

INSTALARE

1. Dacă veți oferi acces CVS prin pserver, adăugați o linie în /etc/inetd.conf precum

cvspserver stream tcp nowait nobody git-cvserver pserver

Notă: Unele servere inetd vă permit să specificați numele executabilului independent de
valoarea lui argv[0] (adică numele cu care programul presupune că a fost executat). In acest
în cazul în care linia corectă din /etc/inetd.conf arată ca

cvspserver flux tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

Doar accesul anonim este oferit de pserve în mod implicit. Pentru a te angaja va trebui
creați conturi pserver, adăugați pur și simplu o setare gitcvs.authdb în fișierul de configurare al
depozitele în care doriți ca serverul cvserver să permită scrieri, de exemplu:

[gitcvs]
authdb = /etc/cvserver/passwd

Formatul acestor fișiere este numele de utilizator urmat de parola criptată, de exemplu:

utilizatorul meu:$1Oyx5r9mdGZ2
utilizatorul meu:$1$BA)@$vbnMJMDym7tA32AamXrm./

Aveți posibilitatea să utilizați htpasswd facilitate care vine cu Apache pentru a face aceste fișiere, dar
Metoda de criptare MD5 a Apache diferă de cea folosită de majoritatea bibliotecii C crypt()
funcția, deci nu utilizați opțiunea -m.

Alternativ, puteți produce parola cu operatorul crypt() al lui perl:

perl -e 'my ($user, $pass) = @ARGV; printf „%s:%s\n”, $user, crypt($user, $pass)' $USER parola

Apoi furnizați parola prin metoda pserver, de exemplu:

cvs -d:pserver:someuser:somepassword server/path/repo.git co

Nu este necesară nicio configurare specială pentru accesul SSH, în afară de a avea instrumente Git în PATH. Dacă
aveți clienți care nu acceptă variabila de mediu CVS_SERVER, puteți
redenumi git-cvserver la cvs.

Notă: versiunile mai noi CVS (>= 1.12.11) acceptă, de asemenea, specificarea CVS_SERVER direct în
CVSROOT place

cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co

Acest lucru are avantajul că va fi salvat în dvs CVS/Root fișiere și nu aveți nevoie
să vă faceți griji pentru a seta întotdeauna variabila de mediu corectă. Utilizatori SSH restricționați
la git-shell nu trebuie să înlocuiți valoarea implicită cu CVS_SERVER (și nu ar trebui) ca
git-shell înțelege cvs ca înseamnă git-cvserver și se preface că celălalt capăt fuge
realul cvs mai bine.

2. Pentru fiecare repo pe care doriți să fie accesibil din CVS, trebuie să editați configurația în repo
și adăugați următoarea secțiune.

[gitcvs]
activat = 1
# opțional pentru depanare
logFile=/path/to/logfile

Notă: trebuie să vă asigurați că fiecare utilizator care urmează să îl invoce git-cvserver are scris
acces la fișierul jurnal și la baza de date (vezi Backend-ul bazei de date. Dacă doriți să oferiți
acces de scriere prin SSH, utilizatorii desigur au nevoie și de acces de scriere la Git
depozitul în sine.

De asemenea, trebuie să vă asigurați că fiecare depozit este „gol” (fără un fișier index Git) pentru
cvs se angajează să lucreze. Vedea gitcvs-migrare(7).

Toate variabilele de configurare pot fi, de asemenea, suprascrise pentru o anumită metodă de acces.
Numele de metode valide sunt „ext” (pentru acces SSH) și „pserver”. Următorul exemplu
configurația ar dezactiva accesul pserver în timp ce permite accesul prin SSH.

[gitcvs]
activat = 0

[gitcvs „ext”]
activat = 1

3. Dacă nu ați specificat CVSROOT/CVS_SERVER direct în comanda de checkout,
salvându-l automat în dvs CVS/Root fișiere, atunci trebuie să le setați în mod explicit
în mediul tău. CVSROOT ar trebui să fie setat în mod normal, dar directorul ar trebui
indicați la depozitul Git corespunzător. Ca mai sus, pentru clienții SSH nu restrictionat la
git-shell, CVS_SERVER ar trebui să fie setat la git-cvserver.

export CVSROOT=:ext:user@server:/var/git/project.git
export CVS_SERVER="git cvserver"

4. Pentru clienții SSH care vor efectua comiteri, asigurați-vă că .ssh/mediul lor de pe partea de server
fișierele (sau .bashrc, etc., în funcție de shell-ul lor specific) exportă valorile adecvate
pentru GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME și GIT_COMMITTER_EMAIL.
Pentru clienții SSH al căror shell de conectare este bash, .bashrc poate fi o alternativă rezonabilă.

5. Clienții ar trebui să poată verifica acum proiectul. Utilizați CVS modul nume pentru
indicați ce Git cap vrei să verifici. Aceasta setează și numele noului tău
directorul verificat, cu excepția cazului în care îi spuneți altfel cu -d . De exemplu,
asta verifică maestru ramificație în directorul proiect-master:

cvs co -d proiect-master master

BAZA DE DATE BACKEND

git-cvserver folosește o bază de date pentru fiecare cap Git (adică modul CVS) pentru a stoca informații despre
depozitul pentru a menține numerele de revizuire CVS consistente. Baza de date trebuie să fie
actualizat (adică scris la) după fiecare comitere.

Dacă commit-ul se face direct folosind git (spre deosebire de utilizarea git-cvserver) actualizarea
va trebui să se întâmple la următorul acces la depozit până la git-cvserver, independent de acces
metoda si operatia solicitata.

Aceasta înseamnă că, chiar dacă oferiți doar acces de citire (de exemplu, folosind metoda pserver),
git-cvserver ar trebui să aibă acces de scriere la baza de date pentru a funcționa în mod fiabil (în caz contrar, dvs
trebuie să vă asigurați că baza de date este actualizată în orice moment git-cvserver este executat).

În mod implicit, folosește baze de date SQLite în directorul Git, numit
gitcvs. .sqlite. Rețineți că backend-ul SQLite creează fișiere temporare în fișierul
același director ca fișierul bazei de date la scriere, așa că ar putea să nu fie suficient pentru a acorda utilizatorilor
folosind git-cvserver acces de scriere la fișierul bazei de date fără a le acorda acces de scriere
la director, de asemenea.

Baza de date nu poate fi regenerată în mod fiabil într-o formă consistentă după ramura în care este
urmărirea s-a schimbat. Exemplu: pentru sucursalele comasate, git-cvserver urmărește doar o ramură
de dezvoltare, iar după a merge îmbina o bază de date actualizată progresiv poate urmări a
ramură diferită de o bază de date regenerată de la zero, provocând CVS inconsecvenți
numere de revizuire. git-cvsserver nu are de unde să știe ce ramură ar fi ales dacă
a fost rulat progresiv înainte de îmbinare. Deci, dacă trebuie complet sau parțial (de la vechi
backup) regenerează baza de date, ar trebui să fii suspicios de sandbox-urile CVS preexistente.

Puteți configura backend-ul bazei de date cu următoarele variabile de configurare:

Configurarea Baza de date backend
git-cvserver folosește modulul Perl DBI. Vă rugăm să citiți și documentația acesteia dacă schimbați
aceste variabile, în special despre DBI->connect().

gitcvs.dbName
Numele bazei de date. Semnificația exactă depinde de driverul de bază de date selectat, pentru SQLite
acesta este un nume de fișier. Acceptă înlocuirea variabilelor (vezi mai jos). Poate să nu conțină
punct și virgulă (;). Mod implicit: %Ggitcvs.%m.sqlite

gitcvs.dbDriver
Driver DBI folosit. Puteți specifica orice driver disponibil pentru aceasta aici, dar s-ar putea să nu fie așa
muncă. cvserver este testat cu DBD::SQLite, raportat că lucrează cu DBD::Pg și
raportate nu a lucra cu DBD::mysql. Vă rugăm să priviți aceasta ca pe o caracteristică experimentală.
Nu poate conține două puncte (:). Mod implicit: SQLite

gitcvs.dbuser
Utilizator baze de date. Util doar dacă setați dbDriver, deoarece SQLite nu are conceptul de
utilizatorii bazei de date. Acceptă înlocuirea variabilelor (vezi mai jos).

gitcvs.dbPass
Parola bazei de date. Util doar dacă setați dbDriver, deoarece SQLite nu are conceptul de
parolele bazei de date.

gitcvs.dbTableNamePrefix
Prefixul numelui tabelului bazei de date. Acceptă înlocuirea variabilelor (vezi mai jos). Orice
caracterele nealfabetice vor fi înlocuite cu caractere de subliniere.

Toate variabilele pot fi, de asemenea, setate pe metoda de acces, vezi mai sus.

Variabil substituție
În dbDriver și dbUser puteți utiliza următoarele variabile:

%G
Numele directorului Git

%g
Numele directorului Git, unde toate caracterele, cu excepția celor alfanumerice, . și -
sunt înlocuite cu _ (acest lucru ar trebui să faciliteze utilizarea numelui directorului într-un
nume de fișier dacă se dorește)

%m
Modulul CVS/Numele capului Git

%a
metoda de acces (una dintre „ext” sau „pserver”)

%u
Numele utilizatorului care rulează git-cvserver. Dacă nu poate fi determinat niciun nume, numărul numeric
este folosit uid.

MEDIUL

Aceste variabile înlătură necesitatea opțiunilor de linie de comandă în anumite circumstanțe, permițând
utilizare restricționată mai ușoară prin git-shell.

GIT_CVSSERVER_BASE_PATH ia locul argumentului la --base-path.

GIT_CVSSERVER_ROOT specifică o listă albă cu un singur director. Depozitul trebuie să fie în continuare
configurat pentru a permite accesul prin git-cvserver, așa cum este descris mai sus.

Când aceste variabile de mediu sunt setate, este posibil ca argumentele corespunzătoare din linia de comandă să nu fie
fi folosit.

ECLIPSE CVS CLIENT NOTE

Pentru a obține o plată cu clientul Eclipse CVS:

1. Selectați „Creați un nou proiect → Din finalizarea CVS”

2. Creați o nouă locație. Consultați notele de mai jos pentru detalii despre cum să alegeți corect
protocol.

3. Răsfoiți module disponibil. Vă va oferi o listă a capetelor din depozit.
Nu veți putea să răsfoiți arborele de acolo. Doar capete.

4. Alegeți HEAD când întreabă ce ramură/etichetă să verifice. Debifați „asistentul de lansare de comitere”
pentru a evita comiterea fișierului .project.

Note de protocol: dacă utilizați acces anonim prin pserver, selectați-l. Acestea
folosind acces SSH ar trebui să aleagă ext protocol și configurați ext acces pe
Preferințe → Echipa → CVS → Panoul ExtConnection. Setați CVS_SERVER la „git cvserver”. Rețineți că
suportul pentru parole nu este bun atunci când se utilizează ext, cu siguranță veți dori să aveți chei SSH
înființat.

Alternativ, puteți utiliza doar protocolul extssh non-standard pe care îl oferă Eclipse. În
în acest caz, CVS_SERVER este ignorat și va trebui să înlocuiți utilitarul cvs pe
server cu git-cvserver sau manipulați .bashrc astfel încât apelarea cvs apeluri efectiv
git-cvserver.

CLIENTI CUNOSCUT LA MUNCĂ

· CVS 1.12.9 pe Debian

· CVS 1.11.17 pe MacOSX (din pachetul Fink)

· Eclipse 3.0, 3.1.2 pe MacOSX (consultați Notele clientului Eclipse CVS)

· Broască țestoasăCVS

OPERAȚII SPRIJINIT

Toate operațiunile necesare pentru utilizarea normală sunt acceptate, inclusiv checkout, diff,
stare, actualizare, log, adăugare, eliminare, comite.

Majoritatea argumentelor comenzii CVS care citesc etichete CVS sau numere de revizuire (de obicei -r) funcționează și
acceptă, de asemenea, orice refspec git (etichetă, ramură, ID de comitere etc.). Cu toate acestea, numerele de revizuire CVS
pentru ramurile care nu sunt implicite nu sunt bine emulate, iar jurnalul cvs nu arată etichete sau ramuri
deloc. (Numerele de revizuire ale CVS care nu aparțin ramurilor principale seamănă superficial cu numerele de revizuire ale CVS,
dar codifică de fapt un ID de comitere git în mod direct, mai degrabă decât să reprezinte numărul de
revizuiri de la punctul de ramificare.)

Rețineți că există două moduri de a verifica o anumită sucursală. După cum este descris în altă parte
această pagină, parametrul „modul” al cvs checkout este interpretat ca un nume de ramură și acesta
devine ramura principală. Rămâne ramura principală pentru un anumit sandbox, chiar dacă tu
face temporar o altă ramură lipicioasă cu cvs update -r. Alternativ, argumentul -r
poate indica o altă ramură pentru a face checkout, chiar dacă modulul este încă
"ramura principală. Compensații (așa cum sunt implementate în prezent): Fiecare „modul” nou creează un nou
baza de date pe disc cu un istoric pentru modulul dat, iar după crearea bazei de date,
operațiunile împotriva acelei ramuri principale sunt rapide. Sau, alternativ, -r nu necesită niciun plus
spațiu pe disc, dar poate fi semnificativ mai lent pentru multe operațiuni, cum ar fi actualizarea cvs.

Dacă doriți să vă referiți la o specificație git refspec care are caractere care nu sunt permise de CVS, dvs
au doua variante. În primul rând, poate funcționa doar pentru a furniza git refspec direct către
argument CVS -r adecvat; unii clienți CVS nu par să efectueze prea multă verificare a logicii
argument. În al doilea rând, dacă nu reușește, puteți utiliza un mecanism special de evadare a caracterelor care
folosește numai caractere care sunt valide în etichetele CVS. O secvență de 4 sau 5 caractere din
formularul (subliniere ("_"), liniuță ("-"), unul sau două caractere și liniuță ("-")) poate codifica
diferite caractere bazate pe una sau două litere: „s” pentru bară oblică (“/”), „p” pentru punct
("."), "u" pentru liniuță de subliniere ("_") sau două cifre hexazecimale pentru orice valoare de octet
(de obicei, un număr ASCII, sau poate o parte a unui caracter codificat UTF-8).

Operațiunile de monitorizare vechi nu sunt acceptate (editare, vizionare și conexe). Exporturile și
etichetarea (etichete și ramuri) nu sunt acceptate în această etapă.

CRLF Linie Sfârșit Conversii
În mod implicit, serverul părăsește -k mod gol pentru toate fișierele, ceea ce determină clientul CVS
pentru a le trata ca fișiere text, supuse conversiei la sfârșit de linie pe unele platforme.

Puteți face ca serverul să folosească atributele de conversie de la sfârșitul liniei pentru a seta -k moduri pentru
fișiere prin setarea variabilei de configurare gitcvs.usecrlfattr. Vedea gitattributes(5) pentru mai mult
informații despre conversia finală.

Alternativ, dacă gitcvs.usecrlfattr config nu este activat sau atributele nu permit
detectarea automată a unui nume de fișier, apoi serverul folosește configurația gitcvs.allBinary pentru
setarea implicită. Dacă gitcvs.allBinary este setat, atunci fișierul care nu este specificat altfel va
implicit la -kb modul. Altfel cel -k modul este lăsat necompletat. Dar dacă gitcvs.allBinary este setat
a „ghici”, apoi corect -k modul va fi ghicit pe baza conținutului fișierului.

Pentru cea mai bună consistență cu cvs, cel mai bine este probabil să anulați valorile implicite prin setare
gitcvs.usecrlfattr la adevărat și gitcvs.allBinary la „ghici”.

DEPENDENȚE

git-cvserver depinde de DBD::SQLite.

GIT

O parte din merge(1) apartament

Utilizați git-cvserver online folosind serviciile onworks.net