Pravidla nachadzajuce sa na tejto stranke su v sucasnosti navrhom. Po upravach a schvaleni sa tato poznamka vyhodi a stanu sa zavazne.
Aby sa zamedzilo viacnasobnemu pridavaniu podobneho textu je ako prve potrebne vyhladat slovo a podobne vyrazy. V pripade, ze uz existuje stranka s podobnym obsahom je potrebne zvazit ci nie je vhodne pridat novy text do predchadzajuceho prispevku.
Ak je potrebne spravit branch zo starsej revizie tak pouzijeme prikaz v konzole
“svn copy -r *revizia cesta_z cesta_do”
Standardne branch-ovanie len s reviziou
revizia - cislo revizie, ktore urcuje po ktoru reviziu si prajeme zmeny v branch-y. Je je napriklad 20050 si uz neprajeme tak tam dame 20049 a vieme ze v branch-y uz nemame nove zmeny
Pri mergeovani sa nenechava nevyrieseny konflikt. Nie je teda mozne komitovat po mergenuti kod ktory pouziva iba jednu vetvu, alebo ma konflikt ako komentar. V pripade neschopnosti riesenia mergeovacieho konfliktu sa kontaktuje nadriadeny ktory urci cloveka alebo skupinu ludi ktora vyriesi konflikt.
Na mergovanie sa odporuca pouzivat softver “KDESVN”. Program automaticky vytvara poznamky do properties-ov kam branch mergujeme. Properties projektu obsahuje informacie ktory branch bol kedy mergnuty a po ktoru reviziu. Je to dolezite pre spravu branch-ov.
Po prebehnuti merge-u nastava niekedy problem, ze su modifikovane properties(mergeinfo) aj nad nekorenovymi adresarmi. Mergeinfo property maju mat len korenove adresare ako trunk, ESlave, EOnboardComputer a podobne. Cpp aj H subory nemaju obsahovat v svn repozitari mergeinfa.
Problem sa da vyriesit nadriadenym: ( Pozor, prikaz vykonavajte v podpriecinku so suborom, s ktorym mate problem. Nepouzivajte prepinac -R !!! )
svn propdel svn:mergeinfo ./file
Tento prikaz je potrebne vykonavat s velkym pozorom na to aby sa nezmazali merge-infa v korenovom adresari. Startili by sa infromacie o branchovani a mergeoch
Pri poziadavke na zmenu v konfiguracnom subore (pridanie polozky / zmena polozky / zmena struktury) sa to najprv skonzultuje s veducim teamu. Ten potom na zaklade porovnania a konzultacie s produktovym / analytikom a so sucasnymi nastaveniami rozhodne co dalej. Cielom je aby sa nezaviedlo duplicitne nastavenie, ktore bude alebo v dvoch konfiguracnych suboroch alebo v subore aj v Back office systeme (rozumej winade).
V pripade zmeny v konfiguracnom subore sa upravi adektvatne aj dokumentacia tu: Konfiguracne subory.
Projekty ktore maju dizajn / analyzu v Enterprise Architekte a maju nastavene cesty ku zdrojovym kodom je potrebne pred tym ako sa v modeli robia upravy aktualizovat so zdrojakmi. Ked by aj nic ine, tak to usetri vela problemov a casu.
cislovanie 2.4 vs. 2.6. Pozri aj: pravidla cislovania brancheovych verzii.
Aby bolo mozne na zaklade define-ov “KNIZNICA_MAJORVERSION” v kniznici kompatibilne vykompilovat aj pre stare a nove projekty( na zaklade define-u vieme urcite casti kodu ifdefnut na verziu kniznice )
Nastavenie a vyuzitie plus ine poznatky najdeteme v odkaze verzionovania kniznic.
Verzionovanie kniznic: Nastavenie Major, Minor a Maintance verzii kniznice
Na zneplatnenie funckie pre dalsie pouzivanie s apouziva makro:
//don't use me any more DEPRECATED(void OldFunc(int a, float b)); //use me instead void NewFunc(int a, double b);
pricom je dane v libke basedefs ako:
#ifdef __GNUC__
#define DEPRECATED(func) func __attribute__ ((deprecated))
#elif defined(_MSC_VER)
#define DEPRECATED(func) __declspec(deprecated) func
#else
#pragma message("WARNING: You need to implement DEPRECATED for this compiler")
#define DEPRECATED(func) func
#endif