CVS, SVN hozzáférés menedzsment

Linux-haladó

Sziasztok!

Nemrég jött három új PHP fejlesztő a cégünkhöz. Ezzel együtt már öten vannak, és persze ugyanazon a kódon kell dolgozniuk.

Ez eddig nem is volna baj. A probléma ott kezdődik, hogy nem mind fog ugyanazon a projekten dolgozni, és nem mindnek kellene, hogy meg legyen engedve, hogy közvetlenül módosítsa a kódot a production szerveren. Ugyanakkor valami verziókövetés, rollback-lehetőség, branchek és hasonlók is kellenének.

A csapat vezetője azt szeretné megoldani, hogy: 1) csak neki legyen joga kódot "kirakni élesbe", 2) a srácok el tudják küldeni a változtatásokat, amit ő "hagyna jóvá", 3) lehessen követni ki-mit csinált és 4) bármikor szinte bármelyik állapotra vissza tudjon rollbackelni... Ja és nem akarnak ún. "release"-eket csinálni, ahol egyszerre nyomnak ki számos változtatást, hanem a webszerver mindíg az aktuális verziót "látná", ha jól értelmezem, amit akartak...

CVS és SVN doksit olvasgattam, de nem értem, hogy ezt a jóváhagyásos, követéses dolgot hogyan tudnám megvalósítani. Ilyet még nem csináltam. Van erre bevált technika vagy esetleg más rendszer? :(

  • 1781 megtekintés

( nyasi | 2007. 08. 06., h – 09:35 )

A beküldős jováhagyás dologokat nem fogod ugyanígy megtalálni cvs-ben (se svn-ben)

1), 2)
Szerintem külön ág (brach) lenne a megoldás.
A fejlesztők egy branchben dolgoznának. Ide commitolnak és a "főnök" emeli át (merging) az általa jóváhagyott változtatásokatabba az ágba (akár lehet a HEAD is) ahol a jováhagyot kódhalmaz van.
Ez biztosítaná azt ,hogy ne vesszen el kód ha a főnök még nem hagyta jóvá.
A merging-hez viszont kicsit több odafigyelés kell de ezt válallnia kell a "főnöknek"

3) "Lehessen követni ki-mit csinált " : erről szóla verziókövetés :-)

4) "bármikor szinte bármelyik állapotra vissza tudjon rollbackelni.."
Az állapotokat meg címkézéssel (tagging) kellene megoldani

Én legalábbis így csinálnám.
HA CVS mellet döntesz mindenképpen cvsnt-t használj (ne tévesszen meg a neve van linux/unix verziója is)

Remélem segítettem :-)

( ssikiss | 2007. 08. 06., h – 10:26 )

Az egyrepós megoldásnak az a hátránya, hogy a kommit jog az egészre vonatkozik, a többrepósnak meg, hogy kicsit nehézkesebb a repók közti merge kivitelezése és naplózása/követése.

Az svn-ben vannak un. hook-ok (szkriptek futtathatók kommit előtt/után, és az eredmény alapján megáll, vagy folytatódik a folyamat), amivel lehet finomítani a hozzáférési szabályokat.

Eseleg lehet keresni olyan verziókövetőt, ami (kicsit "kényelmesebben") támogatja a finomabb hozzáférésszabályozást.

Valami elosztott verziókövetőt is lehet használni, ahol mindenki a saját repójában "dühöng", és valami közösbe nyomják fel a dolgaikat, ahonnan a főfejlesztő vállogat és mergel a sajátjába , tesztel és nyom egy "élesbe". De húzhat direktben a fejlesztőitől is, ahogy jólesik, szóval itt másféle struktúra és munkamenet is elképzelhető.

( aperger | 2007. 08. 06., h – 10:49 )

Szia,
Én is azt javaslom, hogy a főnök (project vezető fejlesztője) emelje át a (MERGE) az egyik, általában "TRUNK" nevezett könyvtár alatt lévő fejlesztői verzióból a szükséges dolgokat a "BRANCH" alatt lévő éles verzió alá (Így ezt a "Checkout"-olt könyvtárat kell csak frissíteni az éles szerveren!
Én csak "Apache"-csal tudom elképzelni a megoldást, hogyha HTTPS-en keresztül éri el mindenki a REPOSITORY-kat, mert azt hogy egy projekt alatt ki mihez férhet hozzá, azt az Apache alatt a #Locale, #LocaleMatch, #AuthUserFile, #AuthGroupFile használatával le tudod szabályozni (Apache 2.x, WebDAV (mod_dav.so), Subversion (mod_dav_svn.so), SSL (mod_ssl.so)).
Így a megoldáshoz én az SVN-t használnám, jó grafikus kliensek vannak hozzá, mind Linux (kdesvn), mind Windows (TortoiseSVN + WinMerge 2.6.x) alatt.

Perger Attila

és még egy link épp erről szól a minta (AuthzSVNAccessFile beállítás):
http://svnbook.red-bean.com/en/1.1/ch06s04.html

Pl.:

Once your basic Location block is configured, you can create an access file and define some authorization rules in it.

The syntax of the access file is the same familiar one used by svnserve.conf and the runtime configuration files. Lines that start with a hash (#) are ignored. In its simplest form, each section names a repository and path within it, and the authenticated usernames are the option names within each section. The value of each option describes the user's level of access to the repository path: either r (read-only) or rw (read-write). If the user is not mentioned at all, no access is allowed.

To be more specific: the value of the section-names are either of the form [repos-name:path] or the form [path]. If you're using the SVNParentPath directive, then it's important to specify the repository names in your sections. If you omit them, then a section like [/some/dir] will match the path /some/dir in every repository. If you're using the SVNPath directive, however, then it's fine to only define paths in your sections—after all, there's only one repository.

[calc:/branches/calc/bug-142]
harry = rw
sally = r

In this first example, the user harry has full read and write access on the /branches/calc/bug-142 directory in the calc repository, but the user sally has read-only access. Any other users are blocked from accessing this directory.

Of course, permissions are inherited from parent to child directory. That means that we can specify a subdirectory with a different access policy for Sally:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

# give sally write access only to the 'testing' subdir
[calc:/branches/calc/bug-142/testing]
sally = rw