reklama

Obdoba RCS $Log$ v gitu

kimec

Re:Obdoba RCS $Log$ v gitu
« Odpověď #15 kdy: 20. 03. 2017, 09:01:41 »
Vyhrál návrh kolegy Ovrscout. Vytvořil jsem si skript, který to zabalí a očísluje.
Potom se to publikuje na místo odkud se to bere pro nasazení.
Místo publikace je vztažná soustava od které se bere číslování verzí.

Děkuji za pomoc a přeji hezký zbytek víkendu.
Tento model je zdanlivo jednoduchy, ale moja hlavna vyhrada voci nemu je, ze potrebujete externy skript/program, ktory musite "imperativne" zavolat a musite ho mat na svojom systeme spustitelny. Akonahle mate kolegov s roznymi systemami, tak mozete mat problem.
Kazdopadne, super, ze ste vyriesili svoj problem.

Git je takový dost relativistický.
S touto myslienkou velmi opatrne. V gite sice mate moznost robit cary mary s grafom commitov ale fakt je, ze kazdy commit v gite hovori o absolutnom stave celeho vasho repozitara - teda commit v gite neobsahuje ziadne informacie o tom, co sa zmenilo. Gitove commity su defacto snapshoty.
Nepochopenie/ignorovanie tohto faktu vedie k takymto zaverom http://r6.ca/blog/20110416T204742Z.html a k tejto diskusii https://www.reddit.com/r/programming/comments/grqeu/git_is_inconsistent/.

Pokial git povazujeme za file system so snapshotovanim, je jasne, ze vyhrada autorovho blogu, ze git nesplna merge associativity law, je bezpredmetna.

Casto krat si ludia myslia, ze git je DARCS, ktory si skutocne pamata zmeny.
Git ma vsak blizsie k ZFS https://zef.me/who-needs-git-when-you-got-zfs-e9cd11aba8ea#.vh490nuvf . Pritiahnute za vlasy, keby ZFS malo mergeovaci nastroj na snapshoty, netreba git.

reklama


 

reklama