Remélem nem kérdezek nagy ostobaságot :D
Van egy remek svn szerverem, benne vagy 50 apró project. Amit el szeretnék érni, hogy
- egyik-másik projectben vannak olyan dolgok, amiket szeretnék publikussá tenni
- ám sok olyan dolog van benne, amit nem (egész pontosan az egyik shell scriptet igen, a másikat nem)
- ezért olyan kellene, hogy svn-en beül csinálnék két "edition"-t, az egyikben benne van minden, a másikban csak az, amit mindenki láthat
- a teljest csak usernév/jelszó párossasl lehessen elérni
- a publikust bárki tudja olvasni
- ha a privátot - vagy a publikust - módosítom, akkor természetesen az mindkét helyen változik
- a már meglévő könyvtárstruktúrát nem akarom megbontani
- externalsok is vannak bőven, és azok is olyanok, hogy az externalsban definiált path-on is vannak olyan dolgok, amik épp így két editionra kellene hogy legyenek bontva.
Megoldható ez svn-ben? Ha svn-ben nem, akkor esetleg valami hasonlóban, pl. git?
- 5735 megtekintés
Hozzászólások
Miert nem irsz egy publikalo scriptet ami feltolja valami masik SVN-be?
Esetleg egy SVN hook ami ezt teszi?
Te csak a privatot modositod, es van egy SVN hookod ami ha a fajlnev benne van vmi maintainelt text fajlban, akkor felkuldi a publikusra is.
- A hozzászóláshoz be kell jelentkezni
Ez volt az első gondolatom, de milyen remek lenne, ha meg lehetne tartani a kétirányú fejlesztést. Azaz ha valaki a publikus hókuszpókuszba beletesz valami hasznosat, akkor az egyből meglegyen az úgymond privát cucc alatt is.
- A hozzászóláshoz be kell jelentkezni
Szia!
Fájlokat linkelni az SVN nem tud. Azaz, nem megoldható, hogy ugyan az az állomány több könyvtárban látszik, és ha bárhol módosul, a változások mindenhol megjelennek. Én eddig csak SourceSafe -ben és Sourcegear Vault -ban láttam ilyet (meg olyan eszközökben melyekért kemény pénzeket kérnek.)
Véleményem szerint a linkelés mérsékelten praktikus és hamar a szakadék szélére vezet. Szerintem praktikusabb lenne modulokra bontani a programodat, ezeket verziózni, adott verziójú modulok halmazából build -et, vagy releaste -t definiálni, majd ezeket kiadni. Így 100% -ban megmarad a rugalmasság, azaz nem kell 100 évig branch -ben lennie egy módosításnak csak azért, mert a másik ág még nem tudja átvenni egyéb problémák miatt. (Itt emlékezzünk meg a két ág fejlődési ágai közötti kölcsönös konfliktusról, azaz amikor mind a két ágban van olyan módosítás ami a másik ágat üti.)
Ha már modulokat definiálsz, lehet két tárolód is, egy a publikus moduloknak meg egy a privátoknak. Ez a hozzáférési kérdéseket megoldja. Mondjuk az SVN képes könyvtáranként, vagy akár állományonként szabályozni a hozzáférést.
Az egyik módszerrel sem úszod meg, hogy nyilvántartsd melyik módosítás mivel kompatibilis és mivel nem, milyen feature -ört hogyan tervezel megvalósítani, és így tovább. Minek is nevezik ezt? Configuration meg Build management? A linkelős módszernél a feltöltés pillanatában kell eldönteni, jöhet e a módosítás, a modulos verziónál release előtt. Ez utóbbit az esetleges külsős fejlesztők jobban fogják szeretni.
Hosszú távol biztosan jobban jársz, ha átgondolod már most mit és hogyan szeretnél megszervezni.
- A hozzászóláshoz be kell jelentkezni
"Fájlokat linkelni az SVN nem tud."
Ellenben van externals.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
authz-vel tudsz valamennyire szűrni, de szerintem evvel az igényeddel nagyon egyedül vagy a világon.
- A hozzászóláshoz be kell jelentkezni
Ha jol olvasom ez a fejezet a referencia doksiban pont errol szol.
Nem kell ket fele vagni a projektet, path szerint lehet donteni anonymous es authentikalt eleres kozott.
- A hozzászóláshoz be kell jelentkezni
Az már csak hab a tortán, hogy ezt a trac-al is össze kéne illeszteni, de már annak is örülnék, ha megnyugtató megoldást látnék 1 trac-ban kezelt sok kis projektre.
- A hozzászóláshoz be kell jelentkezni