"Multi root" systém správy verzí

[Great Lama]

Zdravím konferenci,

V práci jsme si pořídili speciální tester (bohužel), který má velmi specificky vyřešeno ukládání sekvencí. Změna testeru ani způsobu ukládání sekvencí bohužel není možná.

* Každá sekvence musí být uložena v adresáři LeonardoOS2
* LeonardoOS2 by musí být umístěn v kořenovém adresáři (např. c:\LeonardoOS2)
* Každá sekvence je rozdělena do tří podadresářů
  o LeonardoOS2\FlyTprj.100\ADAPTER
  o LeonardoOS2\FlyTprj.100\BOARD
  o LeonardoOS2\FlyTprj.100\PRJ
* Adresáře ADAPTER, BOARD a PRJ jsou sdíleny všemi sekvencemi
* Každá sekvence má svůj vlastní podadresář uvnitř ADAPTER, BOARD a PRJ
* Podadresář z předchozího bodu je složen z "Název sekvence" + " - V" + "verze"
* Každá sekvence se skládá z cca 2000 souborů (většinou malých)
* Tester jede na windows

Vzhledem k tomu, že na sekvencích pracuje více lidí na více počítačích, tak bych na to rád nasadil nějaký systém správy verzí. Bohužel ale nic co znám si s takovým gulášem neporadí.

Jediné použitelné co mě zatím napadlo je napsat si nějaké klikátko nad třeba SVN, které bude commit a update dělat vždy nad těmi třemi adresáři, ale moc si mi to nelíbí.

Druhá možnost je to pomocí linků předělat do nějaké rozumnějsí formy, ale to by taky vyžadovalo kázeň a mám obavu, že by se to dřív nebo později rozsypalo. (SVN linky na windows neumí, u GITu si nejsem jist)


Poradíte mi nějaký klidně exotický systém správy verzí, který by si s tímto poradil?

Předem děkuji
H.
P.S. Příklad struktury adresárů

Kód: [Vybrat]

C:\LeonardoOS2\FlyTprj.100\ADAPTER\SEKVENCE_A - V1
C:\LeonardoOS2\FlyTprj.100\ADAPTER\SEKVENCE_A - V2
C:\LeonardoOS2\FlyTprj.100\ADAPTER\SEKVENCE_B - V2

C:\LeonardoOS2\FlyTprj.100\BOARD\SEKVENCE_A - V1
C:\LeonardoOS2\FlyTprj.100\BOARD\SEKVENCE_A - V2
C:\LeonardoOS2\FlyTprj.100\BOARD\SEKVENCE_B - V2

C:\LeonardoOS2\FlyTprj.100\PRJ\SEKVENCE_A - V1
C:\LeonardoOS2\FlyTprj.100\PRJ\SEKVENCE_A - V2
C:\LeonardoOS2\FlyTprj.100\PRJ\SEKVENCE_B - V2

[Reklama]

[Filip Jirsák]

Co chcete mít verzováno pohromadě (jako jedno repository)?

Git má docela dost možností, jak mohou repository vypadat „netradičně“. Nejprve ale potřebujeme vědět, co vlastně chcete do jednoho repository a co má být víc repository.

[Great Lama]

Omouvám se, tohle jsem zapomněl napsat...

Není to striktní požadavek, ale předpokldámám vše v jednom repozitáři.

Připadně repozitáře po projektech (pak by ale stejně obsahovaly více sekvencí).

Mít každou sekvenci (budou jich stovky) jako jeden repozitář by byl asi trochu opruz, ale také je to možné.

----

Co je pro mě důležité je omylem při commitu nebo update nepřepsat sousední sekvenci. Jak jsem psal souborů je v sekvenci cca 2000, takže ručně to hlídat moc nejde.

[Filip Jirsák]

Pokud to chcete jako jedno repository, stačí nastavit commit hooky, kterými se bude kontrolovat, že uživatel nemění něco, co nemá. Pokud budete pro synchronizaci používat centrální server, je nejjednodušší nastavit to tam. Uživatel pak sice může udělat chybný commit, ale už ho přes push neprotlačí na centrální server a ostatním. Pokud byste měl jen lokální repository, hooky mohou být i tam – pak je to samozřejmě na zodpovědnosti těch uživatelů, že ty hooky nebudou měnit.

[RDa]

Nebude snazsi si udelat "mount to path" a checkout provadet do virtualniho (ram-)disku?

Pripadne rekurzivne vytvorit hardlinky do mist, kde to appka testeru ocekava, z prave aktivni vetve podle testovaneho objektu.

[Reklama]

[Great Lama]

Pokud to chcete jako jedno repository, stačí nastavit commit hooky...

Dekuji za reakci, dival jsem se na ty hooky a vypada to jako mocny nastroj. Ale to co chci ja uz je asi trochu na hrane, nebo mozna spis za ni.

Jako soucast "meho" systemu by to bylo fajn, ze by server treba pomoci hooku kontroloval, ze se vzdy commituje a updatuje svata trojice dohromady a nekdo tam at uz schvalne nebo omylem nerozbiji integritu.

Ale pro realne pouziti ve vyrobe se mi to zda malo. System spravy verzi budou primarne pouzivat technologove ve vyrobe. Takze to musi byt co nejjednodussi. (nemuzu je nutit aby z CLI commitovali tri adresare naraz)

Pokouset se zmermomocnit hooky k tomu, aby mi pri commitu jednoho adresare commitovaly i dalsi dva uz mi prijde za hranou toho co chci provozovat (pokud by to vubec slo)...

Takze se mi zda, ze hooky muzu provozovat, ale pouze v kombinaci s nejakym klikatkem pro technology, neco co by umoznilo update, commit a revert vzdy pouze svate trojice dohromady.

Diky H.

P.S. O gitu vim malo, takze se predem omlouvam jestli mastim commit a update s push a pull na jednu hromadu...

[Great Lama]

Nebude snazsi si udelat "mount to path" a checkout provadet do virtualniho (ram-)disku?

Pripadne rekurzivne vytvorit hardlinky do mist, kde to appka testeru ocekava, z prave aktivni vetve podle testovaneho objektu.

Jak tester tak pocitace technologu jsou windows stanice.

Cesta s linkama se mi libila, hodne libila, ale take neni uplne jednoducha. Zkousel jsem to pomoci https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink

1) sekvence je treba vytvaret z programu co je k testeru, ten je logicky vytvori do sve blo struktury
2) pak bych musel mit nejaky (trivialni) skript, ktery mi k nove vytvorenym sekvencim dodela linky do nejake inteligentni struktury
3) nad touhle inteligentni strukturou pak muzu delat snadno operace typu commit a update
4) Pochopitelne by bylo potreba doresit stavy co se bude dit, kdyz v programu od testeru sekvenci smazu, prejmenuju...

Trochu blby je co se stane, kdyz si chci stahnout na svuj pocitac sekvenci kterou delal nekdo jinej, pak bych logicky chtel, aby se mi stahla do blbo struktury a zaroven se mi udelaly linky (samy od sebe, nebo zase nejakym trivialnim skriptem)


SVN na windows praci s linkama neumi https://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html

GIT moc neznam, ale taky jsem dosel k nazoru, ze to snadno nepujde.

---

Co jsem jeste nerekl je, ze je fajn kdyz jsou sekvence ulozeny na lokalnim disku pocitace, kde se s nima pracuje. Ze sitoveho disku to pouzivat jde, ale pokles vykonu je celkem citelny.

[Filip Jirsák]

Ten hook na serveru by jen kontroloval, že commit obsahuje všechny tři adresáře.

Na klientovi by na commitnutí stačilo napsat jednoduchý skript. Pokud uživatel commituje vždy ten samý adresář, skript by ani nemusel mít parametry (případně by měl jako parametr text commit zprávy – ale možná by bylo lepší commit zprávu generovat skriptem). Pokud jeden uživatel commituje více různých adresářů, buď by skriptu předával jako parametr název adresáře, nebo by skript mohl detekovat, ve které adresáři byl spuštěn a zachovat se podle toho.

Pokud to chcete klikací, nainstalujte jim Altap Salamander – v něm budou procházet adresáře a pracovat se soubory. Na nástrojovou lištu jim dáte ikony, kterými budou spouštět ty skripty. Skriptu předáte jako parametr aktuální adresář a skript podle toho provede commit správné trojice.

[RDa]

Podle me bys tu testovaci stanici mel brat jako "deployment point" a drzet si vsechny skripty ve vlastni strukture, nezavisle jak to tester vyzaduje.

Az se nekdo rozhodne testovat, tak si checkoutne urcity tag dle toho co dela, pusti "deploy.cmd" ktery nacpe co kam treba a pak az tester. Pak muzes mit treba uninstall, ale ja bych to delal do ramdisku no, jestli tester sw vezme jakekoliv pismeno jednotky.

[Great Lama]

Ten hook na serveru by jen kontroloval, že commit obsahuje všechny tři adresáře.

Na klientovi by na commitnutí stačilo napsat jednoduchý skript.

S tim commit update skriptem je to reseni, ktere jsem planoval.

Bez hooku se mi to zdalo trochu nebezpecne, s hookama se mi to zda o dost lepsi. Diky

[Wasew]

SPEA umí pracovat se ZIPováním a importem/exportem projektů. Tohle by mohla být cesta pro tester. 

[Great Lama]

Podle me bys tu testovaci stanici mel brat jako "deployment point" a drzet si vsechny skripty ve vlastni strukture, nezavisle jak to tester vyzaduje.

Az se nekdo rozhodne testovat, tak si checkoutne urcity tag dle toho co dela, pusti "deploy.cmd" ktery nacpe co kam treba a pak az tester. Pak muzes mit treba uninstall, ale ja bych to delal do ramdisku no, jestli tester sw vezme jakekoliv pismeno jednotky.

Na testeru musi bohuzel probihat i velka cast vyvoje (odhadem 1/3 doby). Nejaky deployment tam bude, ale formu jeste nemam rozmyslenou. Spis to bude jenom formalni.

Jakekoli pismenko to zere, v ramdisku nevidim vyhodu. Viz predchozi bod - budu chtit commitovat i z testeru.

Je to tester ve vyrobe, takze technolog pripravi a odladi program, ktery nasledne budou pouzivat operatori. Tedy nekdo kdo jeste vcera rovnal v tescu zbozi do regalu. Ti uz muzou jenom pipnout cteckou cislo karty a zalozit ji do testeru. Nic slozitejsiho po nich nemuzu chtit.

[Great Lama]

SPEA umí pracovat se ZIPováním a importem/exportem projektů. Tohle by mohla být cesta pro tester.

Ano to je pravda, ale je to strasne naprd. Kdyz se v projektu hrabou dva lidi najednou, tak tyhle zipy neohlidaji zadne kolize, nic...

Je to tak, ze odpoledne poslu technologum mail, vecer se budu vrtat v programu XY, tak na nej nesahejte. A pak jim poslu mail. Upravil jsem program a nahral ho na sitovy disk, tak si stahnete novou verzi...

Je to jako se vratit v case o 20 let...

[Ondrej Nemecek]

Chápu to správně, že Ti vývojáři budou pracovat naživo ve společném adresáři C:\LeonardoOS2\FlyTprj.100 přímo na tom testovacím stroji? Tj. ve stejném checkoutu? (Pokud ne, můžete klidně rozdělit dle sekvencí na samostatné projekty nebo branche stejného projektu a nemusíte nic moc řešit.)

[RDa]

Na testeru musi bohuzel probihat i velka cast vyvoje (odhadem 1/3 doby). Nejaky deployment tam bude, ale formu jeste nemam rozmyslenou. Spis to bude jenom formalni.

Tak to asi zas nejaky pre-commit script, ktery vezme zivou strukturu z appky a transformuje do formatu ktery je v repu.

Jako drzel bych repo v logicky nejrozumnejsim formatu a z nej sel do formatu testeru skrze transformace. Ve tvem pripade obouma smery, protoze budes chtit upravovat kvuli rychlosti vyvoje tu deploynutou verzi.