ugrás a tartalomhoz

Szerkrendszer verziókezelésnek kell-e branch kezelés?

janoszen · 2006. Jún. 17. (Szo), 20.40
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
 
1

+1

janoszen · 2006. Jún. 17. (Szo), 20.44
Még egy kérdés: szerintetek, érdemes / lehetséges összefűzni az SVN vagy CVS verziókezelésével a fájlokat? Lehetségessé tenni az ezeken keresztül való feltöltést?
2

Nem tudom...

Pal_ur · 2006. Jún. 17. (Szo), 23.19
... hogy szükséges-e, de nekem jól jött volna, ha nem is szerkesztő(ségi) rendszerhez, hanem CRM rendszerhez integrált CVS (vagy SVN) .... És nem találtam.
3

nem kell feltetlenul cvs.

dOMiNiS · 2006. Jún. 17. (Szo), 23.42
diff es patch meg valami adatbazis nem jo?
4

Szóval kell...

janoszen · 2006. Jún. 17. (Szo), 23.42
:sigh: csak nem úszom meg. Szóval kell... :) Kicsit kifejtenéd, hogy mire is kellett volna? (Ötletgyűjtés, ugyanis elég sok mindent kell ennek a kis csodának tudnia.)

Az még rejtély előttem, hogy hogy varázsolom össze a PHPt meg a CVSt/SVNt...
6

cvs oncommit

zsepi · 2006. Jún. 18. (V), 16.52
Ha jól tudom, CVS-ben modulonként be tudsz állítani egy kvázi oncommit eseménykezelőt, amivel egész sok mindent meg lehet valósítani.
  • 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
  • telepíts cvs szervert
  • szinkronizáld a tartalomkezelő usereket a cvs userekkel
  • az adatbeküldést-módosítást cvs-en keresztül kezeld, majd az onkommit pakolja az adatbázisba az éles adatokat
  • visszaállításra meg írj egy modult
8

Járható útnak tűnik...

janoszen · 2006. Jún. 18. (V), 18.35
Köszi, ez járható útnak tűnik, a szerver dedicated szerverként fog működni, mert a rendszernek meg fogom követelni, tehát nem probléma bármilyen szoftvert telepíteni, de nem vagyok annyira jó C programozó, hogy biztos legyek a dolgomban. Inkább az a kérdés, hogy milyen belső verziókezelést valósítsak meg ahhoz, hogy minél jobban igazodjon az SVN-hez (miután ez a jobbik, mint olvastam a doksijában).
5

Tisztázzuk

Bártházi András · 2006. Jún. 18. (V), 10.07
Te most magát a szerkesztőségi rendszert szeretnéd verziókezelni, vagy pedig az általa kezelt tartalmat (cikkek, cikkek képei, stb.)? Az indítódból azt veszem ki, hogy magát a szerkesztőségi rendszert, ebben az esetben viszont teljesen irreleváns, hogy szerkesztőségi rendszerről van-e szó.

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.
7

Tartalmakat verziókezelni...

janoszen · 2006. Jún. 18. (V), 18.32
Tartalmakat szeretnék verziókezelni. A programkód verziókezelését és frissítését megoldottam, ezzel nincs baj.

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).
9

Amenyiben...

Nagy Péter · 2006. Jún. 18. (V), 18.48
a tartalmak szöveges állományokként kezelhetők akkor javaslom tekintsd meg a php SVN kiterjesztését. Szerintem ezzel mindent meg tudsz oldani. Ha jól olvasom akkor a libsvn funkcionalitását hozza PHP alá. Egy próbát megér, így "csak" az SVN szervert kell belőni és ezen keresztül csatlakozni hozzá. Win-es verzióban is létezik.

Nem teszteltem, csak googliztam.
--
NP
10

Hülyeség?

Bártházi András · 2006. Jún. 18. (V), 20.44
Ha jól értem, akkor nagyon-nagy hülyeségről beszélgetünk, jajj. :) Az SVN nem adatbázistartalom verziókezelésére van kitalálva, valami nagy fogalomzavar van itt kérem.

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.
11

Nem véletlen!

Nagy Péter · 2006. Jún. 18. (V), 21.49
Nem véletlenül kezdtem úgy ez előző hozzászólásomat, hogy
Amennyiben a tartalmak szöveges állományokként kezelhetők
De mint azt proclub 18:32-kor írta, tartalmakat szeretne verziókezelni.
12

Tudom

janoszen · 2006. Jún. 19. (H), 10.52
Tudom, hogy nem arra való. :D De nem is az volt a kérdés.

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
13

Hááát....

Nagy Péter · 2006. Jún. 19. (H), 13.34
Használtam már CMS-t többet is. Nem igazán hiányzott a verziókezelés.
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
14

Szóval, nem kell?

janoszen · 2006. Jún. 19. (H), 17.08
Szóval nem kell? A Wikiben van verziókezelés, ha megnézed... annak van értelme, nem?

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...
15

Melyik?

Pal_ur · 2006. Jún. 19. (H), 19.28
Bocs, melyik blogmarkban?

Egyébként szerintem a workflow mellé igenis szükséges lehet akár dokumentumokra is verziókövetés...
16

Elfelejtettem...

janoszen · 2006. Jún. 19. (H), 20.54
Uh, már nem tudom. A cikk szerzője azt javasolta, hogy filenév.verziószám.kiterjesztés formátumú legyen a fájlnév, mire én fölhorkantam, hogy mire valók a cache-control headerek.

Akkor visszatérve az eredeti témára: kell-e branch kezelés a verziómenedzsmentnek?
17

Kell-e

Bártházi András · 2006. Jún. 19. (H), 22.31
Kell-e automata váltó a kocsimba? Nem látom a fókuszt, hogy miről beszélgetünk? Kell-e kép az oldalamra? Kell-e fórum az oldalamra? Igen, mert az jó? Ja, hogy egy céges oldal lesz? Akkor meg nem. Ja, hogy egy céges oldal, aminek a lényege, hogy összegyűjtsed a felhasználóid véleményét?

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.
18

attól függ... ;)

Hodicska Gergely · 2006. Jún. 19. (H), 22.37
...hogy mire is van szükség. Annyiban egyet értek Péterrel, hogy túlzásba nem érdemes vinni, az esetek többségében inkább workflow kezelésre lehet szükség, de azt azért el tudom képzelni, hogy mondjuk kikerül egy cikk, majd a szerzője szeretné updatelni: itt jól jöhet, hogy egy másolaton tud dolgozni.

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ő
19

Egy kicsit más architektúra...

janoszen · 2006. Jún. 20. (K), 07.27
Egy kicsit más az architektúra, minthogy nem teszek különbséget az adatok között, tehát mind a cikket mind a képet virtuálisan fájlként látja. Innentől leredukálódik a probléma a fájl verziózására és a hivatkozások frissítésére. De ha ennyi elég, nem kell branch kezelés (elég, ha tud "draft copy"-kat csinálni) akkor elég egyszerű a probléma.

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)
20

Beszéltem néhány emberrel...

janoszen · 2006. Jún. 20. (K), 21.12
Sziasztok!

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
21

az mi az?

Hodicska Gergely · 2006. Jún. 20. (K), 22.12
Már csak az a kérdés, hogy jelen esetben mit értesz "branch" kezelés alatt. Amit egy verziókezelő esetén jelent, annak nem sok értelmét látom, pedig szoktam szakmabeliekkel beszélgetni. ;)


Felhő
22

Szál, elágazás...

janoszen · 2006. Jún. 20. (K), 22.55
A verziókezelésben elágazást / külön verziószálat értek alatta. Remélem, helyesen. :)

Én pl egy építészmérnökkel beszélgettem arról, hogy neki mik lennének az igényei egy ilyen rendszerrel szemben... :)
23

use case

Hodicska Gergely · 2006. Jún. 21. (Sze), 00.09
Én pl egy építészmérnökkel beszélgettem arról, hogy neki mik lennének az igényei egy ilyen rendszerrel szemben... :)

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ő
24

ArchiCAD tervek, szálak...

janoszen · 2006. Jún. 21. (Sze), 09.03
Az illető úgy nyilatkozott, hogy egy-egy projekt során előfordul, hogy kipróbálnak különböző verziókat egy-egy terven és ezt publikálni is kell adott esetben, de az egyik szálat a kettő közül 1-2 hét múlva elvágják. Szal szükség lehet rá.

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.