Stoku artikol-historion en Git

[wdiestel]

Noto 12/2019: Paralela konservado en Git (revo-fonto) jam estas realigita kaj teste ruliĝas. Necesos poste fari ankoraŭ:

• forigonte CVS-konservadon: kontroli version kompare kun la versio en Git anstataŭ tiu en CVS
• farita: ~renovigi revo-fonto kaj transiri de testo al normala paralela procedo~
• permesi flegi rekte en Git kaj per repoŝto: tiam necesos aldoni "git pull" (merge)

• pliajn aferojn ankoraŭ pripensindajn, ekz. uzi "Github Actions" por afido k.s.

Ĝis nun artikol-historioj estas deponitaj per CVS, kio havas kelkajn malavantaĝojn:

• Necesas centra deponejo, el kiu nur estas du plej aktualaj kopioj. Kontraŭe Git ne bezonas centran deponejon kaj povas havi pli da distribuitaj kopioj
• CVS estas malnova, ne subtenas Unikodon (aparte necesas Askio en kmentoj), kaj atendeble iam baldaŭ ĝi ne plu estos flegata de la Linuks-eldonoj

Krome uzante Git mi esperas, ke ni povos iom post iom forigi la bezonon sendi redaktojn per retpoŝto. Anstataŭe la redaktilo povus ekz. rekte sekurigi al github.com. Tiel ni havus ankaŭ ĉiam publike alireblan historion de artikoloj tie.

farita: ~Unua paŝo estus aldoni konservadon al Git-deponejo en processmail.pl - CVS verŝajne plu necesas tiom longe, kiel la publika Revo-servo uzas precipe Perlo, kiel programlingvo.~

Solvenda problemo: la komparo, ĉu redakto baziĝas sur la aktuala versio, momente funkcias per aŭtomate flegata versio en argumento $Id$ ŝovitan en ĉiun artikolon. Ankaŭ la ŝanĝoj malsupre kolektiĝas per $Log$. Ambaŭ traktiĝas aŭtomate de CVS. Git ne havas tiajn aŭtomatajn argumentojn. Do ni devas aparte realigi tian kontrolon per alia rimedo:

• ~kontrolo povus okazi per kontrolsumo - tamen tiun oni ne povas ŝovi en la artikolon mem, ĉar tio ŝanĝus la sumon. Do ni bezonas aŭ apartan lokon, kie memori la kontrolsumon aŭ pendigi ĝin kape aŭ voste de artikolo en parto, kiu ne estas kunkontrolata.~
• farita: ~la versio de artikolo devas ankaŭ iel aŭtomate altiĝi aŭ ni transiros al tiuj haketoj (hases), kiujn uzas Git por versioj. Numero ŝajnas al mi pli homtaŭga.~
• la lastajn ŝanĝojn oni ne nepre bezonas en la artikolo mem, se la historio en Github estas publike rigardebla.

Se tio estas realigita, sekva paŝo povos esti traktado de novaj redaktoj rekte el Git- anstataŭ CVS-deponejo. (vd. ĉe voko-formiko)

[wdiestel]

La laŭbezona kreado de la artikol-historio en Git estas tra malrapida (ĉ. 1min por unu artikolo). Do mi decidis krei la historiojn kiel dosieroj paralele kun la artikol-prezento. Por ĉiuj artikoloj samtempe tio estas pli efika (20min), sed ankaŭ dum aktualigo de unuopaj artikoloj la daŭro estas ne tiom grava.