Szerkrendszer verziókezelésnek kell-e branch kezelés?
Kedves fórumozók!
Szerintetek, egy webes szerkesztőségi rendszer verziókezelésének mit kell tudnia? Az ötlet onnan jött, hogy a wiki-kben vissza lehet állítani egy korábbi verziót.
Más verziókezelők viszont, pl a CVS vagy a subversion, tudtommal tudnak kőlönböző szálakat (branch) kezelni. Szerintetek, szükség van erre webes rendszer esetében?
Gyakorlatilag minden webről elérhető adatot (HTML, CSS, képek, letöltés) verziókezelhetővé szeretnék tenni.
Köszi
J
■ Szerintetek, egy webes szerkesztőségi rendszer verziókezelésének mit kell tudnia? Az ötlet onnan jött, hogy a wiki-kben vissza lehet állítani egy korábbi verziót.
Más verziókezelők viszont, pl a CVS vagy a subversion, tudtommal tudnak kőlönböző szálakat (branch) kezelni. Szerintetek, szükség van erre webes rendszer esetében?
Gyakorlatilag minden webről elérhető adatot (HTML, CSS, képek, letöltés) verziókezelhetővé szeretnék tenni.
Köszi
J
+1
Nem tudom...
nem kell feltetlenul cvs.
Szóval kell...
Az még rejtély előttem, hogy hogy varázsolom össze a PHPt meg a CVSt/SVNt...
cvs oncommit
- megvalósították a teljes projekt fordítását, s ha a unittestek nem sikerültek, akkor visszautasította a commit-ot (eXtreme Programming)
- anno valahol olvastam olyat, hogy a cvs logokat automatikusan postgre-ba rakta.
szóval biztos megoldható.Amennyiben komolyan gondolod a tartalom verziókezelést, s van lehetőséged a szerverhey hozzányúlni, akkor
Járható útnak tűnik...
Tisztázzuk
A verziókezelés minden fejlesztést támogatni, segíteni tud. Ha nem egy ember fejleszt egy rendszert, akkor kötelező, ha sokat próbálgatsz, szeretnél visszaállni, akkor is. Bármilyen fejlesztésnél.
Tartalmakat verziókezelni...
Ugyanakkor felvetődött az, hogy a verziókezelést SVN-kompatibilissá kellene tenni.
A lényeg az, hogy egy viszonylag jó adatbázis struktúrát próbálok ehhez kialakítani és ezért kérdeztem, hogy milyen feature-öket kellene támogatnia.
Ha SVN kompatibilis lesz, akkor arra három megoldást tudok elképzelni. a) lesz egy SVN import/export modul (funkcionalitás szempontjából sok értelme nincs) b) SVN-t használok verziókezelésnek (lassú lesz és nem tudok minden belső adatot eltárolni vele) c) saját SVN szervert írok (overkill).
Amenyiben...
Nem teszteltem, csak googliztam.
--
NP
Hülyeség?
Nem saját "SVN" szervert (mégegyjajj) kell írni, hanem saját verziókezelést, ami a gyakorlatban nem több, mintha írnál egy interfészt az SVN-hez: le kell kezelni az egyes műveleteket.
Nem véletlen!
Tudom
Szal még egyszer:
1. Milyen verziókezelés fícsöröket kell támogatnia egy olyan rendszernek, amely szöveges tartalmakat IS és pl képeket IS szeretne verziókezelni?
2. Kell-e olyan lehetőség, hogy mondjuk a képeket SVN interfészen keresztül fel lehessen tölteni a szerverre?
Remélem, így már világos, mit szeretnék... :D
Hááát....
Biztonsági mentésnek sok, workflow helyett kevés.
Én inkább a tartalom publikálására helyezném a hangsúlyt.(Azaz jól működő workflow kell hozzá)
Ha pedig létezik a "biztonsági mentés" feature a rendszerben, akkor szerintem mindent tud, ami elvárható. Legalább is az "offline" sajtóban sem hallottam róla, hogy "verziókezelnének".
--
NP
Szóval, nem kell?
A workflow teljes menetét szted lehet rendszerrel megtámogatni?
Egyébként onnan jött az ötlet, hogy volt itt szó egy blogmarkban verziókezelésről, hogy filenevekkel meg ilyesmi és az nem tetszett...
Melyik?
Egyébként szerintem a workflow mellé igenis szükséges lehet akár dokumentumokra is verziókövetés...
Elfelejtettem...
Akkor visszatérve az eredeti témára: kell-e branch kezelés a verziómenedzsmentnek?
Kell-e
Alapvetően nem verziókezelés kell a szerkesztőségi rendszerbe, hanem nem kell új szerkesztőségi rendszer. Mert van rengeteg... Hogy ez egy speciális lesz? Miben? Hogy a tanulást szolgálja? Jó, de akkor meg miért kérdés?
Áruld már el, hogy miről beszélünk! Ennél sokkal fókuszáltabb bejegyzésekre szóltam tőled, a jelenlegi társalgás csak arra jó, hogy tök értelmetlenül elbeszéljünk egymás mellett, mivel mindenki tök másról beszél.
attól függ... ;)
Egy kellően jó alap megoldás lehet, hogy egy van egy cikk táblád, amiben csak egy id, meg egy current_version_id van. Aztán van egy táblád a cikk verzióknak. A képeket meg úgy tárolnám, hogy lenne nekik egy külön tábla (persze a képek nem muszáj DB-ben legyenek), és ezt egy kapcsoló tábla kötné össze a cikk verziókkal. Amikor egy cikkből létre hozunk egy új verziót, akkor a képeekt nem bántjuk, csak a kapcsolótáblában jön létre egy új sor. Amikor egy képet törlünk, akkor is csak az itteni bejegyzés törlődik, de ha az adott képre nincs több hivatkozás, akkor fizikailag is töröljük őket. Ezáltal a képek mindig csak egy példányban lesznek fizikailag jelen, viszont mégis "verziózottak". Kicsit olyan ez mint a PHP "write-on-modify" módszere.
Felhő
Egy kicsit más architektúra...
Köszi a hozzászólást, sokat segített. :)
(Kis kitérő: kedvencem az OpRe nevű tárgyból a COW, azaz a tehén-flag volt. Copy-on-write. :D :P)
Beszéltem néhány emberrel...
Beszéltem néhány random szakmabeli emberrel, hogy nekik mire is lenne szükségük publikálás terén és kiderült, hogy érdemesebb az elején implementálni a branch kezelést mint később esetleg azzal szívni, hogy az elején nem gondoltam rá, ugyanis szükség lehet rá...
Gondoltam, közlöm a végeredményt. :)
Köszi a véleményeket
János
az mi az?
Felhő
Szál, elágazás...
Én pl egy építészmérnökkel beszélgettem arról, hogy neki mik lennének az igényei egy ilyen rendszerrel szemben... :)
use case
Kíváncsi lennék mi az a use case, amikor erre lehet szükség. Persze nyogodtan implementáld, de általánosságban szerintem csak egy olyan featur, ami feleslegesen bonyolítja a usereid életét.
Felhő
ArchiCAD tervek, szálak...
Ami a felhasználókat illet, alapesetben nem látják a szálkezelést, csak ha "advanced módba" lépnek. Tehát ügyesen el van rejtve előlük. Gyk. az egész verziókezelés csak akkor látszik, ha megkattintja a "dokumentum történelem" gombot.