Az svn merge ignoráljon néhány fájlt

 ( Fisher | 2012. március 1., csütörtök - 23:16 )

Van a trunk és van egy (pár) branch. A konfig fájlok is az svn-ben vannak, ám értelemszerűen más kell legyen (legalább részben) a konfig a trunk és a branch alatt. Jól látom, hogy nincs arra megoldás, hogy a merge kihagyja egy-egy fájl vagy könyvtár változásait mergekor?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ehm, nem veletlen, hogy sok helyen az a szabaly, hogy konfigokat nem commitolunk a verziokovetobe. Csak a gond van vele. Toroljetek ki az svn-bol, tegyetek ignore-ra az egeszet, es kesz. Ha kell, lehet peldakonfigot felrakni, ami egy mukodo konfig is lehet akar, de jelszavak meg ilyenek ne legyenek benne.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tehát nincs, és kézzel kell megoldanom?

Igen. Merge es revert egy lehetseges mod. Vagy atszervezed a konfig fajlok rendszeret, ha megoldhato. Kulon konfigot csinalsz annak ami-nek az svn-ben a helye es kulon, aminek helyi hatasa van csak (branch fuggo). Utobbiak mehetnek ignore. Aztan, ha az is megoldhato ezeket a helyi konfig fajlokat aztan automatice ranthatja be a fo konfig fajl.

A konfigok általában eleve gépfüggőek, hostnév alapján tölti be őket a script. Ám most ugyanazon a gépen van mindkét ág, és így problémás a dolog egy kicsit.

De eleve nem ertem, miert commitoljatok be a konfig fajlokat. Van koze a kodhoz? Nincs. Van koze az eles rendszerhez? Nincs. Ennyi erovel akkor mar egy komplett eclipse-t (vagy a ceges IDE-t) is be lehetne committolni, hatha valakinek nincs a gepen.

Szoval, szerintem maga a gyakorlat hibas. Arra mar nem is ternek ki, hogy gepnev alapjan... az uj kollega beleptetese meg ugy nez ki, hogy svn cp fishergepe.ini pistikegepe.ini ? Nonsense.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem mindegy, hogy alkalmazas konfig vagy IDe-konfigrol van szo. Az alkalmazas konfignak a verziokezeloben a helye. Alapelv: minden olyan info, ami egy eles/teszt/whatever buildhez kell, a verziokezeloben kell legyen pont azert, hogy barki barmikor tudjon egy azonnal deployolhato buildet kesziteni (lehetoleg automatikus eszkozokkel).

A cél pontosan ez volt. Igaz nem ennél az apró fejlesztésnél, hanem egy másik apró fejlesztésnél, ahol fontosnak véltem, hogy mindig friss legyen az adott tree, ezért kb. úgy indul az egész, hogy svn up, és csak utána jön az érdemi rész.

Azóta ez nem annyira vált be, noha akkor még jó ötletnek tűnt. Így viszont sok gépen lehet elavult app, amit valami módon követni kell, de ez már egy másik probléma, és nem is igazán jelentős.

Az alkalmazaskonfignak akkor van ott a helye, ha az minden gepen ugyanaz, vagy ha viszonylag keves (1-3) konfigverziot kell supportalni, es ezt az alkalmazas kepes a konfig fajlon belul elkezelni (pl. ini fajl eseteben a szekcio neve az adott "gep" neve.

Minden mas esetben csak hibaforras, es lehetoleg kerulendo. Lattam olyan projektet, ahol baromi egyszeruen oldottak meg: a per-gep konfig konkretan adatbazisbol jott, vagy a szerveren volt felvezetve valami konfigba amibe bele lehetett irni az uj gephez tartozo parametereket. Es ezek olyan parameterek voltak, hogy mittomen, a gepen levo soros porti eszkoz melyik porton log. Nem kellett svn-be commitolni, nem volt gond, ha atdugta masikba, az egesz problema nem letezett.

Szoval, meg lehet ezt oldani. Az automatikus eszkokhoz meg annyit, hogy majdnem minden eszkozt lehet automatizalni. Egy jo build script akarmilyen forrasbol megirja neked a deployolhato buildbe a konfigot, nem kell ehhez svn.

Arrol nem beszelve, hogy mivel itt per-gep konfigrol beszelunk, jo esellyel az ugyfelnel ugyis totalisan mas konfig van, mint ami az svn-ben benne van. Akkor meg hol az ertelme?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"keves (1-3) konfigverziot kell supportalni"

Két verzió van, teszt és éles ("tesztrendszer tulajdonképpen két könyvtárnévben tér el az éles rendszertől")

"es ezt az alkalmazas kepes a konfig fajlon belul elkezelni (pl. ini fajl eseteben a szekcio neve az adott "gep" neve."

v.ö.: "Arra mar nem is ternek ki, hogy gepnev alapjan... ... Nonsense."

"Egy jo build script akarmilyen forrasbol megirja neked a deployolhato buildbe a konfigot, nem kell ehhez svn."

Ez így van, ám én újabban igyekszem a konfigurációkat is svn-ben tartani, pl. apache, exim, miegyéb. Persze most is megtehetném, de ha externalsként adom meg, akkor bukta, ha meg csak úgy belelököm, akkor meg úgyis mindegy.

"jo esellyel az ugyfelnel ugyis totalisan mas konfig van"

Hmm, te tudsz valamit amit én nem... még nem hallottam arról, hogy ezt én ügyfélnek fejleszteném, de majd hétfőn megkérdezem a főnökömet, hogy ez hogy is van.

De ezek a dolgok már icipicit eltérnek az eredeti kérdéstől.

Nem igy van. Buildeleskor a lenyeg, hogy az alkalmazas a maga konfigfile-jat ami a build kornyezetnek megfelelo, behuzza az osszes konfigfile kozul. Maven eseteben ez profilokkal megoldato, autotools is erre valo, stb.
A megfelelo konfig file behuzasa nem verziokezelesi, hanem buildelesi feladat, az alkalmazasnak nem kell a kulonfele szekciokra felkeszulni. n db konfigfilet (ahany kornyezetbe buildelheto az alkalmazas) es n db build profilt kell kesziteni, ezek leirojat verziokezelve tarolni.
Nalunk tipikus az eles, production, ceges teszt es fejlesztoi lokalis build profil. Ez 4 konfigfile jelent, es akar egyszerre tudok barmilyen profilt (akar tobbet is) leforditani, igy eloall 4 darab, az adott kornyezetbe azonnal deployolhato, helyes konfigot tartalmazo alkalmazas.

Az ugyfelnel levo konfigokat is az SVN-ben kell tarolni. Alapelv, hogy hazon beluli buildeleskor elo lehessen allitani egy olyan alkalmazast, ami azonnal deployolhato a celkornyezetbe, legyen az Jancsi, Jozsi fejlesztoi gepe, ugyfel tesztkornyezete, ugyfel eles kornyezete.
Ha ez azert nem teheto meg, mert az ugyfel akarja konfiguralni az alkalmazast, akkor install script kell erre, ami az egyes konfiguralhato reszeket megkerdezi.

A kódhoz elég sok köze van, mert a kód onnét veszi a beállításokat.
Az éles rendszerhez elég sok köze van, a tesztrendszer tulajdonképpen két könyvtárnévben tér el az éles rendszertől (hogy honnét veszi az inputot, és hová teszi az outputot).
Azt viszont én nem értem, hogy egy esetleges új kollégának mi köze van az egészhez. Általában van két konfig, az egyik az éles gépen, a másik a teszt (fejlesztői) gépen és jónapot. A két konfig általában nagyrészt megegyezik, csak bizonyos paraméterekben tér el, pl. db név, a db user/pass, ezért általában van egy nagy konfig, aminek bizonyos részét újradefiniálja a gépspecifikus rész.

Es nem lehet a checkout-ot egy scriptbe csomagolni, ami utan automatice futtathato a megfelelo beallito script? Siman egy kliens oldali post-checkout scriptre gondolok. Ami esetlegesen megkapja parameterkent, hogy teszt vagy eles beallitasokat allitson a konfig fajlokba.